Systems and Methods for Securely Transmitting Large Data Files

ABSTRACT

In methods, systems, and computing devices configured to implement methods of conveying a data file from a first computing device to a second computing device. A referential complex dataset (RCD) is stored in memory of a first computing device and a second computing device. The first computing device may compare bit strings within a data file to bit strings within the RCD to identify a matching bit string in the RCD, generate a set of rules for locating the matched bit string in the RCD, and transmit the rule set to the second computing device. The second computing device may receive the rule set, sequentially use each rule in the rule set to identify corresponding bit strings in the RCD in memory, and copy the identified bit strings into a memory to replicate the data file.

RELATED APPLICATIONS

This application is a divisional application of U.S. application Ser.No. 16/046,564 entitled “Systems and Methods for Securely TransmittingLarge Data Files” filed Jul. 26, 2018 which is a continuation-in-part ofU.S. application Ser. No. 15/493,572 entitled “Systems and Methods forDevice Verification and Authentication” filed Apr. 21, 2017, the entirecontents of which are hereby incorporated by reference.

BACKGROUND

The development of a digital environment has enabled a vast expansion inrapid communication, including the transmission of documents,photographs, movies, and other forms of information media, among otherthings. However, bandwidth is finite, and its scarcity imposes carriagelimitations. For example, conventional email or SMS messaging systemsreadily enable the sending of a single photo, or a small group ofphotos. But such systems do not support the sending of, for example, anentire vacation album of photographs. As another example, the size ofeven a short home movie file exceeds the limits of conventionalcommunication systems (e.g., email, SMS messaging). Typically, in orderto share large files, or large numbers of files, users must resort to athird-party service to post large files to a remote server (e.g.,Dropbox, Google Drive) and then provide a recipient with permission toaccess the remote server so that the recipient can download the file(s)from the remote server.

SUMMARY

Various embodiments include methods of encoding a large file fortransmission by referencing long strings of bits in the file that matchto bit strings within a data set that is shared between a firstcomputing device and a second computing device and only transmitting thereferences, which are referred to herein as rules. Various embodimentsmay include storing a referential complex dataset (RCD) in memory of thefirst computing device and in memory of the second computing device,performing by a processor of the first computing device the followingoperations sequentially on the data file until the entire data file hasbeen processed: comparing bit strings within the data file to bitstrings within the RCD to identify a matching bit string in the RCD,generating a rule for locating the matched bit string in the RCD, andstoring the generated rule sequentially in a rule set; and thentransmitting the rule set to the second computing device.

In some embodiments, storing the RCD in memory of the first computingdevice and in memory of the second computing device may includegenerating, by the processor of the first computing device, a rule forchanging the RCD stored in memories of both the first computing deviceand the second computing device, applying, by the processor of the firstcomputing device, the generated rule to the RCD stored in memory of thefirst computing device to generate a changed RCD, and transmitting therule to the second computing device in a format that will enable aprocessor of the second computing device to apply the rule to the RCD togenerate the changed RCD in the second computing device.

In some embodiments, storing the RCD in memory of the first computingdevice and in memory of the second computing device may includegenerating the RCD by the processor of the first computing device, andtransmitting the RCD to the second computing device for storage. In someembodiments generating the RCD by the processor of the first computingdevice may include analyzing one or more data files representative ofthe data file to be transmitted to identify long bit strings that appearat least a threshold number of times, storing in the RCD each long bitstring that appear at least a threshold number of times, and generatingan index for locating each long bit string stored in the RCD, andwherein generating a rule for locating the matched bit string in the RCDand storing the generated rule sequentially in a rule set comprisesstoring the index for the matched bit string in the rule set. Someembodiments may further include generating metadata corresponding toeach long bit string stored in the RCD that provides information usefulfor comparing data files to the RCD to identify matching long bitstrings, and storing the generated metadata in association with thecorresponding long bit string, wherein comparing bit strings within thedata file to bit strings within the RCD to identify a matching bitstring in the RCD comprises using metadata associated with a matched bitstring in the RCD to determine whether a longer bit string including thesame matched bits exists in the RCD.

Some embodiments may further include storing a subscriber RCD in memoryof the first computing device and in memory of the second computingdevice, performing by the processor of the first computing device thefollowing operations sequentially on the rule set until the entire ruleset has been processed: comparing a bit string of each rule in the ruleset to bit strings within the subscriber RCD to identify a matching bitstring in the subscriber RCD, generating a secondary rule for locatingthe matched bit string in the subscriber RCD, and storing the generatedsecondary rule in a secondary rule set, wherein transmitting the ruleset to the second computing device comprises transmitting the secondaryrule set to the second computing device.

Some embodiments may further include receiving the secondary rule set inthe second computing device, sequentially using each secondary rule inthe secondary rule set to identify corresponding bit strings in thesubscriber RCD in memory, using the identified corresponding bit stringsin the subscriber RCD as rule to identify corresponding bit strings inthe RCD in memory, and copying the identified bit strings into a memoryto replicate the data file. In some embodiments, the data file to betransmitted is a multimedia file and analyzing one or more data filesrepresentative of the data file comprises analyzing one or moremultimedia files having a similarity to the multimedia file to betransmitted.

Some embodiments may further include receiving the rule set in thesecond computing device, sequentially using each rule in the rule set toidentify corresponding bit strings in the RCD in memory, and copying theidentified bit strings into a memory to replicate the data file. Someembodiments may further include processing the replicated data fileusing an application compatible with the data file processed by thefirst computing device.

Various embodiments may include method of receiving a data file in afirst computing device from a second computing device, including storinga referential complex dataset (RCD) in memory of the first computingdevice that matches an RCD stored in the second computing device,receiving a rule set from the second computing device, sequentiallyusing each rule in the rule set to identify corresponding bit strings inthe RCD in memory, and copying the identified bit strings into a memoryto replicate the data file. Some embodiments may further includeprocessing the replicated data file using an application compatible withthe data file. Some embodiments may further include storing a subscriberRCD in memory of the first computing device, receiving a secondary ruleset from the second computing device, sequentially using each secondaryrule in the secondary rule set to identify corresponding bit strings inthe subscriber RCD in memory, using the identified corresponding bitstrings in the subscriber RCD as rule to identify corresponding bitstrings in the RCD in memory, and copying the identified bit stringsinto a memory to replicate the data file.

Various embodiments further include computing devices configured withprocessor-executable instructions to perform operations of the methodssummarized above. Various embodiments further include a system includinga first computing device and a second computing device, each configuredto perform operations of the methods summarized above. Variousembodiments further include a non-transitory processor-readable storagemedium having stored thereon processor-executable instructionsconfigured to cause a processor of computing device to performoperations of the methods summarized above.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and constitutepart of this specification, illustrate example embodiments of theinvention, and together with the general description given above and thedetailed description given below, serve to explain the features of theinvention.

FIGS. 1A-1C are component block diagrams of a communication systemsuitable for use with various embodiments.

FIG. 2 is a component block diagram of a communication device suitablefor use with various embodiments.

FIGS. 3A-3E illustrate relationships among elements of portions ofshared data sets according to various embodiments.

FIG. 4 is a block diagram illustrating a method of encoding a file intoa rule set based on a referential complex database (RCD) according tovarious embodiments.

FIG. 5 is a block diagram illustrating a method of receiving andreproducing a file based on received rule and a shared RCD according tovarious embodiments.

FIG. 6 is a process flow diagram illustrating methods for encoding,transmitting, receiving and reproducing a file using a shared RCDaccording to various embodiments.

FIG. 7 is a process flow diagram illustrating methods for encoding,transmitting, receiving and reproducing a text documents using a sharedRCD according to some embodiments.

FIGS. 8A and 8B are block diagrams illustrating methods of encoding amultimedia file into rule sets based on an RCD according to someembodiments.

FIGS. 9A and 9B are block diagrams illustrating methods of receiving andreproducing a file based on received rule and a shared RCD according tosome embodiments.

FIG. 10 is a process flow diagram illustrating methods for encoding,transmitting, receiving and reproducing multimedia files using a sharedRCD according to some embodiments.

FIGS. 11A and 11B are block diagrams illustrating further methods ofencoding a multimedia file into rule sets based on a primary RCD and asubscriber RCD according to some embodiments.

FIG. 12 is a block diagram illustrating a method of receiving andreproducing a file based on received rules, a shared RCD and a sharedsubscriber RCD according to some embodiments.

FIG. 13A is a process flow diagram illustrating methods for encoding,transmitting, receiving and reproducing multimedia files using a sharedRCD and a shared subscriber RCD according to some embodiments.

FIG. 13B is a process flow diagram illustrating another method forencoding multimedia files using a shared RCD according to someembodiments.

FIG. 13C is process flow diagram illustrating another method fortransmitting multimedia files that have been encoded using a shared RCDby using a subscriber RCD according to some embodiments.

FIG. 14 is a process flow diagram illustrating an example method forgenerating a media-specific RCD based on a multimedia file according tosome embodiments.

FIG. 15 is a component block diagram of a mobile wireless computingdevice suitable for implementing various embodiments.

FIG. 16 is a component block diagram of a portable wirelesscommunication device suitable for implementing various embodiments.

FIG. 17 is a component block diagram of a server device suitable forimplementing various embodiments.

DETAILED DESCRIPTION

The various embodiments will be described in detail with reference tothe accompanying drawings. Wherever possible, the same reference numberswill be used throughout the drawings to refer to the same or like parts.References made to particular examples and implementations are forillustrative purposes, and are not intended to limit the scope of theinvention or the claims.

Various embodiments include systems and methods for sending data files,particularly multimedia files, between computing devices by using ashared data set. The shared data set may be compiled over time, and maybe changed by a computing device occasionally, periodically, and/or uponthe occurrence of a triggering event. Changing or altering the shareddata set may include reordering one or more portions of the data set,adding information to the data set, subtracting information from thedata set, and/or transforming one or more portions of the shared dataset. Changing or altering the shared data set is sometimes referred toherein as “transforming” the shared data set.

In some embodiments, the shared data set may a referential complexdatabase (RCD), which is a complex shared data set that may contain aplurality of files. In various embodiments, the RCD includes a largeamount of binary data, which may be randomized or specially configuredto include strings of bits predicted to appear in files to betransferred. In some embodiments, the plurality of files may include aplurality of image files. In some embodiments, the computing devices mayuse an agreed upon method for altering the RCD so that the RCD changesover time enable both computing devices to alter the RCD whilemaintaining an identical shared data set. In some embodiments, themethod for altering the shared data set may be agreed to by thecomputing devices in advance. In some embodiments, the method foraltering the shared data set may be agreed to dynamically by thecomputing devices (e.g., “on the fly”).

As an example, a shared data set may include two or more image files,and each image file may include numerous pixels (picture elements). Eachimage file may be associated with additional data, such as a time stampor other time information, location information and/or geolocationinformation where the image was obtained, weather information, and thelike. Each pixel may be associated with a large number of informationelements, such as a coordinate location in an image, color, intensity,luminosity, and the like. Each pixel may also be associated with theinformation of its respective image file. Thus, each pixel may beassociated with a large number of information elements, which may beconsidered variables. In some embodiments, the rule set may includeinformation identifying one or more pixels of the shared data set. Insome embodiments, the rule set may include information identifying onepixel of the shared data set, and relationship information that enablesthe identification of one or more other pixels using the identifiedfirst pixel and the relationship information.

However, the shared data set is not limited to image files, and a shareddata set may be generated or compiled using data that may includeidentifiable data elements, and/or in which relationships between oramong two or more data elements may be determined. Examples of such datainclude video files, audio files, biometric samples, location data(e.g., Global Positioning Satellite system data), and the like.

Various embodiments employ processing on a file to be sent thatidentifies large chunks of data that match chunks of data in the RCD anddetermines rules for finding matching chunks in the RCD. The determinedrules can then be transmitted to a computing device that shares the sameRCD, which enables the receiving computing device to reconstruct thefile by using the rules to find the corresponding data chunks and copythe data chunks into a file buffer. The rule to locate a chunk of datain the RCD may be significantly smaller than data itself. This enables alarge amount of information to be conveyed from the transmittingcomputing device to the receiving computing device without actuallytransmitting the data itself because the stream of rules enables arecipient to find the data in their corresponding synchronized copy ofthe RCD. Instead of compressing data, adding error correction data, andthen sending the actual file in packets, the raw binary data is conveyedby the exchange of the RCD in advance. Later, to convey a file to thereceiver, the transmitter sends only the rules for finding the datawithin the RCD, and the receiver uses the rules to find the data toreplicate the file (e.g., video, audio, text, etc.). Thus, large filescan be provided to a receiving computing device without actually sendingthe file. Further, files can be sent and rendered in this manner usingany conventional communication network and protocol, and rendered usingany conventional rendering or editing software compatible with theoriginal file.

Various embodiments have particular applicability in communicationsituations in which conserving bandwidth or transmitting a large amountof information within limited bandwidth is more important than the timerequired to prepare the information for transmission. Such situationsare common in many forms of modern telecommunications. For example,video streaming on-demand via the Internet (e.g., the services providedby Netflix®, Hulu®, YouTube®, etc.) requires uninterrupted playback, butthe video is stored in server farms with the video files formatted fortransmission via Internet protocols hours, days or months in advance ofbeing accessed and played by subscribers. As another example, usersdesiring to use their smart phones to transmit a large image or videofile that exceeds the email or messaging capacity of their networkservice have the option today of forwarding the file via the Internet toa third party, which is slower than a direct transmission.

For example, in the multimedia application, a media service (e.g.,Netflix®, Hulu®, etc.) may deliver the RCD as part of a subscriptionsign-up process. The delay in transmitting the large amount ofinformation that is in the RCD will typically be acceptable to a user aspart of the sign-up or application registration process. Once thatsign-up delivery of the RCD is been accomplished, various embodimentsenable the communication of very large files through the transmission ofrule sets that point to large chunks of data within the RCD to be loadedinto a play buffer so that a media application can render the media asif the media file had been transmitted directly. Thus, with the advancedelivery of the RCD to the recipient computing device and thepre-transmission processing of the information (text, video, audio,etc.) to generate the rule set, large media files can be transmittedthrough limited bandwidth communication channels with fidelity. Thefurther encoding of the file information into rule sets may also enableimproved delivery or rendering of the file by the receiving device.

The use of the RCD as a repository for chunks of binary data indicatedby rule sets solves four problems that are common in communicationsituations.

First, by using rule sets that point to pre-deployed chunks of data,significant data compression is achieved by avoiding sending theinformation itself, by transmitting rules that enable the recipient toreconstruct the information. This ability to compress information fortransmission can be equally applied to data files that have beencompressed by other methods. Thus, greater data compression and greatertransmission efficiency may be achieved using various embodiments.

Second, the rule set provides a form of encryption of the information,since the information itself is not transmitted. Thus, variousembodiments provide an effective means of securing the information, aswell as protecting privacy rights of the users.

Third, by linking the rule sets that are transmitted to the particularRCD in possession of the recipient and the transmitter, the variousembodiments provide an effective protection for intellectual propertyrights. Delivery of the RCD to a recipient via a subscription sign-upprocess provides an efficient digital rights management (DRM) processthat is as robust as the mechanisms employed for “transforming” the RCDat the transmitter and receiver devices as described herein.

Fourth, various embodiments provide robust communication of informationthrough imperfect communication channels by preloading the raw bit levelinformation in the RCD and using short rule set transmissions to enablereplication at the receiver end. This enables high redundancy to beimplemented in the rule set to increase the probability that all rulesets will be received, while ensuring that single bit errors are all buteliminated. These benefits are all achieved using standard communicationchannels and enable support by standard media players.

In various embodiments, the RCD may be any form of data file that hassufficient size and variability in the bit string patterns to supportthe encoding methods. The key is to have sufficient variability andsufficiently extensive bit patterns to enable matching long bit stringsin the RCD to bit strings in the to a file to be transmitted. Forexample, the RCD may range from one or more photographs shared betweentwo parties to a carefully crafted data file that has data patternsstatistically developed to match a particular type of information to betransmitted broadly.

In embodiments suitable for messaging and the exchange of large datafiles between individuals, the RCD may be any large file that is sharedbetween the two parties. For example, a party seeking to send large datafiles to another may first provide a large file, such as a photograph oranother digital image, to the other, followed by rule sets based on thefiles to be transferred and the shared photograph. As a particularexample, if a first party is desires to send a large number ofphotographs to another party, one photograph may be transmitted usingnormal communication protocols, such as messaging or email. For example,if a person desires to transmit vacation photographs to another, theperson may select a particular photograph that is representative of amajority of the photographs to be transmitted. For instance, if themajority of photographs involve scenic views, the suitable photograph toserve as the RCD may be an average scenic view image. Such an image islikely to have large data segments that match data strings in the othersimilar photographs. Once the selected photograph has been transmitted,the sender's computing device performs the operations of developing rulesets for the rest of the photographs to be transmitted, followed bytransmission of the generated rule sets to the other party.

As another example, if a lawyer seeks to send a large number ofdocuments in a secure manner to a client (e.g., a doctor), the lawyermay select a first document that is not necessarily confidential, andsend that document via message or electronic mail to the client. Afterthat, the lawyer's computing device may generate rule sets for the restof the documents to be transmitted using the exchanged document as theRCD. Text documents are likely to include large data segments that matchthose of other written documents, and thus the exchanged documentprovides a suitable RCD. According to various embodiments, transmittingonly the rule set to the client provides a level of encryption suitableto prevent unauthorized parties from “intercepting” the documents, atleast because the documents themselves are not transmitted and the rulesthat are transmitted are only useful when applied to the shared RCD.Further security can be provided by changing the document used as theRCD, or by both the sender and the receiver altering the RCD documentusing the same alteration method.

In some applications, the RCD may be crafted based on statistical mathanalysis of files to be transmitted so that the RCD contains largestrings of binary values representative of the type of data to betransmitted. Thus, the RCD may appear to be complete gibberish in thatthe data within the RCD does not translate to any particular images,characters or usable information. An example of such an application isthe transmission of movies and similar multimedia from a centralrepository (e.g., Netflix®, Hulu®, etc.) to subscribers. In thisapplication, the media supplying service may use a computer to performstatistical analysis on the raw data of a number of movies (or othermedia) to identify large repetitive strings of binary information andarrange the identified strings into a data set with appropriate indexingor addressing capabilities for use in generating rule sets. This may beaccomplished using any of a variety of methods of identifying repeatingblocks of data, including known methods used for compressing data files.As an example, a movie download service may analyze a large number ofmovies within a given genre and use this analysis of such movies togenerate a genre-specific RCD. The reason for this is that the bitpatterns of action films, which include explosions and fast-movingscenes, may have a different characteristic pattern than romantic comedymovies, which will feature more facial images and fewer outdoor scenes.As a video download service anticipates transmitting videos via theInternet over a long period of time, the investment in time and money toperform the statistical analysis of movies to generate genre-specificRCDs is offset by the long-term savings and improved subscribersatisfaction from transmitting movies via data sets linked to RCD datafiles. Further, movie RCD data files may be customized to a particularsubscriber through transformation of the RCD according to an algorithmspecific to the subscriber, thereby also solving the digital rightsmanagement challenge faced by such companies.

In some embodiments, the statistical analysis involved in generating adata file specific RCD may be similar to a process for graphing thefrequency at which particular bit strings appear in the media to betransmitted. The computing device may begin by reading raw bit stringsfrom a file into a buffer and comparing segments of newly read data tosegments already stored in the buffer to identify matching patterns. Assoon as a bit is read that doesn't match a pattern stored in the buffer,the buffer contents may be stored as a first data string in memory. Thecomputer may then continue to read bit strings comparing bit sequencesboth against the strings already stored in memory and against the nextread bid until a pattern break is detected (i.e., the next bit does notmatch a bit in either the buffer or a stored data string), whichidentifies the end of another data segment. As this process iscontinued, larger and larger bit string patterns will be identified. Ifthe bit string being read in matches a stored data string completely,the data string may continue to be stored in a new data file.

A media distributing service implementing various embodiments may usethe RCD as both a mechanism for reducing the bandwidth required totransmit a multimedia file (e.g., a movie) as well as to detect digitalrights and subscription compliance. Subscribers should accept the timerequired to upload the RCD as part of the process and time required toinitiate a subscription. The media distribution service may generate asubscriber-specific RCD from a media-optimized standard RCD bytransforming the data elements so that different rule sets are requiredto access the same bit patterns. Thus, each subscriber may be associatedwith (and may receive) a unique version of the statistically optimizedRCD used by the media distributor. Further, each media distributionservice can generate its own RCD through its own statistical analysis ofmedia files, and such RCDs should not be interchangeable (i.e., asubscriber to one service cannot receive files from another serviceusing the same RCD). Moreover, since each subscriber receives a uniqueversion of the RCD, subscribers cannot share multimedia files by sharingrule sets, because a rule set will only indicate the correct dataelements in one subscriber's RCD.

The media distribution service may generate subscriber-specific RCDs bymoving around or transforming the bit strings according to a proprietaryalgorithm that may be linked to a subscriber reference number. Thus, themedia distribution service need not save an RCD for every subscriber.Instead, the subscriber reference number and the algorithm used toshuffle the basic RCD may be used as part of generating asubscriber-specific rule set for a particular rendition of the mediafile.

To ensure that digital rights are protected, and in particular,preventing unauthorized use or viewing of media files by intercepting orcopying the rule set, the RCD used in a particular download and play outof a media file may be transformed or randomized per the methodsdescribed herein. The further, the rule set for playing a media file maybe adjusted using an algorithm that is tied to the algorithm used intransforming the RCD for a particular plan. Thus, the media distributionservice can provide an appropriate level of security to protect digitalmedia rights while avoiding the need to generate new rule sets for eachsubscriber or each rendition of the media file. While the limitedshuffling of the RCD using such algorithm-based mechanisms tied toindividual subscriber identifiers may not may prevent cracking by asophisticated party, the protections afforded should be more thansufficient to satisfy digital rights protection required by copyrightholders.

Alternatively, the rule set transmitted to a subscriber to enableplayback of a media file may be encrypted using standard multimediadistribution encryption methods. Thus, digital rights managementprotections may be afforded without the need for shuffling the RCD foreach play out. Since the amount of information required to transmit therule set is substantially less than the data required to transmit theentire media file, encryption of the rule set is an affordablealternative.

Generation of subscriber-specific RCD files tied to individualsubscribers may be accomplished simply using a subscriber referencenumber as a shift index. Since shifting the bit locations by a singledigit will render the rule set inoperable, the RCD data set may beshifted by the subscriber-unique reference number. In this way, eachsubscriber will receive a subscriber-specific RCD file and the mediadelivery service can generate that adjust the rule set simply by addingthe subscriber's reference number using binary addition. Many otherforms of transforming or individualizing the RCD files may also be used.

In a further embodiment, media distribution services may simplify themedia RCD by using a second RCD for the purpose of obfuscating orcustomizing the rule set for individual subscribers. In suchembodiments, a primary RCD may be crafted by the media delivery servicethrough statistical analysis of multimedia files (e.g., movies orparticular versions of movies) and organize the bit fields within thatRCD according to a simple index. For example, the most common bitpattern may be identified with the index value ‘1’ and the second mostcommon bit pattern may be indexed with the with “2” and so forth. Whilethis RCD enables simple rule sets (e.g., just the index value forparticular bit string), it may be difficult to transform or develop analgorithm for assembling rule sets associated with the transformed RCD.Therefore, a second RCD that is smaller and used for other determiningrule sets associated with the primary RCD may be used. In suchembodiments, all subscribers may be provided with the primary RCD andindividual subscribers may be provided with a subscriber-specificsecondary RCD that is unique and to each subscriber. In suchembodiments, the media distribution service develops rule sets forrendering a particular media file (e.g., particular movie), and thendetermines a secondary rule set based on the subscriber-specificsecondary RCD that will enable the subscriber's computing device torender the primary rule set. The media distribution service thentransmits the secondary rule set to a subscriber's computing devicerequesting access to a particular media file, and the subscriber'scomputing device uses the received rule set to obtain the primary ruleset (e.g., index values) using the subscriber's secondary RCD, and thenuses the primary rule set to reproduce the media file for rendering by aconventional media player.

Such embodiments have the advantage of simplifying the generation ofprimary RCDs because the need to transform or obfuscate that file isremoved. Digital media rights are still protected by the use of thesecondary RCD, because the rule sets received by a subscriber can onlybe used with that subscriber's secondary RCD. Further, the secondary RCDmay be much smaller, and thus easier to transform according to analgorithm that can be used to simply generate the secondary rule set.Such embodiments retain the advantage of transmitting a smaller data setwhen delivering a media file as well as ensuring that individualsubscribers are managed with respect to digital meteorites andsubscription compliance.

In such embodiments, the media distribution service may download boththe primary RCD or RCDs and the subscriber specific secondary RCD duringthe subscription sign-up process. The secondary RCD may then betransformed each time the subscriber orders a media file, periodically(e.g., monthly with each subscription payment), or not at all, dependingupon the media delivery service's business model. As with otherembodiments, the media rendering application may be a standard player asthe output of the embodiment systems on the subscriber's computingdevice is the standard media bit string for media. Thus, variousembodiments may be implemented as an intermediary media receiverapplication that integrates (e.g., interoperates) with media datatransmission protocols (e.g., Internet protocol) and standard mediaplayers.

Various embodiments may be implemented within a variety of communicationsystems 150, an example of which is illustrated in FIG. 1A. Thecommunication system 150 may include a variety of entities that maycommunicate using a communication network, such as an IoT network 154, alaw firm 156, a defense contractor 158, a subcontractor 160, a bank 162,a health care entity 164, an online commerce entity 166, and a telecomentity 168. Each of the entities 154-168 may communicate with and amongeach other. Each of the entities 154-168 may also communicate with acertificate authority 152. The certificate authority 152 may include oneor more computing devices configured to perform operations to enable theauthentication of a computing device, as further described below. Theentities 154-168 are merely exemplary, and the communication network 150may include a wide variety of entities, including entities that mayhandle health care records, secure communications (e.g., for a businessor government agency), public records, voting systems, financialservices, security brokerage systems, IoT communications, commercialtransactions, and a wide range of other contexts.

Various embodiments may be implemented within a variety of communicationsystems 100, an example of which is illustrated in FIG. 1B. Withreference to FIGS. 1A and 1B, the elements of communication system 100may be used in any of the entities 154-168. The communication system 100may include computing devices 102, 104, 106, and 108. In someembodiments, the computing devices 102 and 104 may include a computingdevice used directly by a user, such as a smart phone, a laptopcomputer, a desktop computer, and the like. It will be understood that auser may operate more than one such computing device similar to thecomputing devices 102 and 104. In some embodiments, the computingdevices 102 and 104 may include one or more IoT devices. Non-limitingexamples of IoT devices include personal or mobile multi-media players,gaming systems and controllers, smart televisions, set top boxes, smartkitchen appliances, smart lights and lighting systems, smart electricitymeters, smart heating, ventilation, and air conditioning (HVAC) systems,smart thermostats, building security systems including door and windowlocks, vehicular entertainment systems, vehicular diagnostic andmonitoring systems, machine-to-machine devices, and similar devices thatinclude a programmable processor and memory and circuitry forestablishing wireless communication pathways and transmitting/receivingdata via wireless communication pathways. The computing devices 102 and104 may also include an unmanned, autonomous, semi-autonomous, orrobotic vehicle capable of travel of travel on land, sea, air, or inspace. The computing devices 102 and 104 may further include a smartfirearm or another processor-equipped weapon or weapon system.

In some embodiments, the computing devices 106 and 108 may include aback-end computing device such as a server. In some embodiments, thecomputing device 108 may communicate with an electronic security system114 over a communication link 130. In some embodiments, the computingdevices 106 and 108 (and possibly the computing device 114) may beoperated by one entity. For example, a health care entity 164 or atelecom entity 168 may operate one or more of the computing devices 106,108, and/or 114. In some embodiments, the computing devices 106, 108,and 114 may be operated by more than one entity.

Each of the computing devices 102, 104, 106, and 108, and the electronicsecurity system 114 may communicate with a communication network 112over a respective communication link 120, 122, 124, 126, 128, and 130.In some embodiments, the communication network 112 may include two ormore communication networks. The communication links 120, 122, 124, 126,128, and 130 may include wired or wireless communication links, and mayfurther include additional devices to facilitate communication betweenthe computing devices 102, 104, 106, and 108, the electronic securitysystem 114, and the communication network 112. Examples of suchadditional devices may include access points, base stations, routers,gateways, wired and/or wireless communication devices, as well asbackhaul communication links that may include fiber optic backhaullinks, microwave backhaul links, and other suitable communication links.

In some embodiments, the computing devices 102, 104, 106, and 108, andthe electronic security system 114 may be part of a secure network, suchas an internal enterprise network, a government agency secure network, avirtual private network (VPN), or another similar network environment.In such a secure network, the communication links 120, 122, 124, 126,128, and 130 may include additional security, such as encryption at oneor more layers (i.e., Open Systems Interconnection (OSI) layers), andother implementations to secure communications along the communicationlinks 120, 122, 124, 126, 128, and 130.

In some embodiments, the computing device 106 may be configured toperform operations related to information transactions in a variety ofcontexts, including, without limitation, health care record management,secure communications, public records management systems, votingsystems, financial services systems, security brokerage systems, as anIoT device controller, to perform a commercial transaction, as well asother contexts. In some embodiments, the computing device 108 may beconfigured to perform operations related to generating and/or obtainingtransitory identities, and authentication of a computing device such asone or more of the computing devices 102, 104, and 106, as furtherdescribed below.

In some embodiments, the electronic security system 114 may beconfigured to perform network monitoring or network security functions,such as a network monitoring system, a key logging system, or anothersimilar system. In some embodiments, electronic security system 114 maydetect an unauthorized user or electronic intruder using or accessingthe communication network 112, and may send an indication to thecomputing device 108 of the detection of the unauthorized user orelectronic intruder. In some embodiments, the electronic security system114 may be configured to monitor for and/or detect unauthorized accessesof a system, memory, network element, or component of a network elementfrom an otherwise authorized user (e.g., an “insider” threat). In someembodiments, the electronic security system 114 may be configured toreceive a command or an indication that a computing device should bede-authorized from access to the communication system. For example, theelectronic security system 114 may be a component or an element of anetwork authorization system, or a human resources system, or a systemthat provides a list of authorized users of the communication system, oranother similar system. In such embodiments, the electronic securitysystem 114 may receive a command or another message indicating that anauthorization of a computing device should be removed or blocked. Insome embodiments, in response to receiving an indication that anunauthorized user or electronic intruder has been detected, that acomputing device authorization should be removed or blocked, or anothersimilar indication, the computing device 108 may send an instruction toone or more of the computing devices 102, 104, and 106 to obtain a newtransitory identity, as further described below.

The communication network 112 may include a variety of communicationnetworks, including communication networks within an entity orenterprise, and external communication networks, publicly availablecommunication networks, and combinations of networks as well asinternetworks, including the internet. The communication network 112 maysupport communications using one or more wired and wirelesscommunication protocols. Each of the communication links 120, 122, 124,and 126 may be two-way wired or wireless communication links. Wirelesscommunication protocols may include one or more radio accesstechnologies (RATs). Examples of wireless RATs include 3GPP Long TermEvolution (LTE), Worldwide Interoperability for Microwave Access(WiMAX), Code Division Multiple Access (CDMA), Time Division MultipleAccess (TDMA), Wideband CDMA (WCDMA), Global System for Mobility (GSM),and other RATs. Examples of RATs may also include Wi-Fi, Bluetooth,Zigbee, LTE in Unlicensed spectrum (LTE-U), License Assisted Access(LAA), and MuLTEfire (a system that uses LTE on an unlicensed carrierband). Wired communication protocols may use a variety of wired networks(e.g., Ethernet, TV cable, telephony, fiber optic and other forms ofphysical network connections) that may use one or more wiredcommunication protocols, such as Ethernet, Point-To-Point protocol,High-Level Data Link Control (HDLC), Advanced Data Communication ControlProtocol (ADCCP), and Transmission Control Protocol/Internet Protocol(TCP/IP).

While the communication links 120, 122, and 124 are illustrated assingle links, each of the communication links may include a plurality ofwired or wireless links, such as plurality of frequencies or frequencybands, each of which may include a plurality of logical channels.Additionally, each of the various communication links 120, 122, and 124may utilize more than one communication protocol.

The computing device 108 may communicate with a data store 110, such asa memory device, database, server device, or another device capable ofstoring data. In some implementations, the data store 110 may store anaudit trail and associated metadata.

The computing device 108 may receive data inputs 140 over time. The datainputs 140 may include information that the computing device 108 may useto generate a data set that can be shared with another computing device(e.g., the computing devices 102, 104, and 106). The data inputs 140 mayinclude, for example, images, photographs, video, sound recordings(e.g., music, ambient sound recordings, or another such recording),biometric information inputs (e.g., facial recognition scans, irisscans, DNA samples, a voiceprint recordings, fingerprints, and thelike), or any other such data input.

Various embodiments may be implemented within a variety of communicationsystems 180, an example of which is illustrated in FIG. 1C. Withreference to FIGS. 1A-1C, the elements of communication system 150 maybe used in any of the entities 154-168. The communication system 180 mayinclude computing devices 184, 186, 188, 190, 192, 194, and 196. Thecomputing devices 190-196 may include network elements, such as fileservers, databases, or other similar network-accessible data sources.The computing devices 184 and 186 may include any form of user-operablenetwork terminal, and may be similar to the computing devices 102 and104. The computing devices 186-196 may be elements in a communicationnetwork 182, access to which may be protected by a device configured toprotect electronic access to the communication network 182, such as afirewall 198.

Conventional communication security implementations, such as thefirewall 198, may protect the network 182 against attacks orexploitation by an external device, such as the computing device 184.However, the firewall 198 may not protect the network 182 againstattacks or explication from a device that is inside the firewall 198,such as the computing device 186.

Various embodiments may include the computing device 188 (which may besimilar to the third computing device 108), which may be configured toperform operations related to generating and/or obtaining transitoryidentities, and authentication of an identity of a computing device suchas one or more of the computing devices 184, 186, 190, 192, 194, and196.

In various embodiments, while the firewall 198 may be employed toperform network operations such as traffic monitoring, gatewayfunctions, routing, and other similar functions, the firewall 198 maynot perform a security function or an authentication function of devicessuch as the computing devices 184 and 186. Rather, in the communicationsystem 180, the computing devices 184 and 186 may communicate with thecomputing device 188 and/or with each other, enabling authentication ofan identity of each of the computing devices 184 and 186, as well as, insome embodiments, an identity of the computing device 188. Similarly,while the communication system 180 may use inputs received at thecomputing device 184 or 186, such as a username and password, toidentify a purported user or as a pointer to a user account,communication system 180 may not use credentials such as a username andpassword for security purposes or for authentication purposes. Rather,the communication system 180 may authenticate the identity of thecomputing devices 184 and 186 based on transitory and/or dynamicinformation of each computing device, as further described below.

FIG. 2 is a component block diagram of a computing device 200 suitablefor implementing various embodiments. With reference to FIGS. 1 and 2,in various embodiments, the computing device 200 may be similar to thecomputing devices 102, 104, 106, and 108.

The computing device 200 may include a processor. The processor 202 maybe configurable with processor-executable instructions to executeoperations of the various embodiments, a specialized processor, such asa modem processor, configurable with processor-executable instructionsto execute operations of the various embodiments in addition to aprimary function, a dedicated hardware (i.e., “firmware”) circuitconfigured to perform operations of the various embodiments, or acombination of dedicated hardware/firmware and a programmable processor.

The processor 202 may be coupled to memory 204, which may be anon-transitory computer-readable storage medium that storesprocessor-executable instructions. The memory 204 may store an operatingsystem, as well as user application software and executableinstructions. The memory 204 may also store application data, such as anarray data structure. The memory 204 may include one or more caches,read only memory (ROM), random access memory (RAM), electricallyerasable programmable ROM (EEPROM), static RAM (SRAM), dynamic RAM(DRAM), or other types of memory. The processor 202 may read and writeinformation to and from the memory 204. The memory 204 may also storeinstructions associated with one or more protocol stacks. A protocolstack generally includes computer executable instructions to enablecommunication using a radio access protocol or communication protocol.

The processor 202 may also communicate with a variety of modules forunits configured to perform a variety of operations, as furtherdescribed below. For example, the processor 202 may communicate with acommunication interface 206, an authentication module 208, a hashingmodule 210, a transitory identity module 212, the hash storage module214, and a transaction module 216. The modules/units 206-216 may beimplemented on the computing device 200 in software, and hardware, or ina combination of hardware and software. Firmware, chip, system-on-a-chip(SOC), dedicated hardware (i.e., “firmware”) circuit configured toperform operations of the various embodiments, or a combination ofdedicated hardware/firmware and a programmable processor. The processor202, the memory 204, and the various modules/units 206-216 maycommunicate over a communication bus or any other communicationcircuitry or interface.

The communication interface 206 may include a network interface that mayenable communications with a communication network (e.g., thecommunication network 112). The communication interface 206 may includeone or more input/output (I/O) ports through which a connection, such anEthernet connection, a fiber optic connection, a broadband cableconnection, a telephone line connection, or other types of wiredcommunication connection may be provided. The communication interface206 may also include a radio unit that may enable radio frequencycommunication.

The authentication module 208 may provide or be in communication withone or more input devices to receive an input from a user for login tothe computing device 200. The input devices may include one or morebuttons, sliders, touchpads, keyboards, biometric input devices,cameras, fingerprint readers, and other similar input devices.

The transaction module 216 may enable communication related to atransaction (as well as other communications) with another computingdevice (for example, between the computing device 102 and the computingdevice 106). In some implementations, the transaction module 216 mayinclude hardware and/or software configured to provide a streamlinedcommunication and/or transaction process with the transaction server. Insome implementations, the transaction module may include hardware and/orsoftware configured to provide a streamlined communication related to aspecific service provider, such as a so-called “1-click” service oranother streamlined communication/transaction process.

FIG. 3A illustrates one example of a shared data set 300 a, according tosome embodiments. In some embodiments, the shared data set may includetwo or more portions. Each portion of the shared data set may includeone or more elements. In some embodiments, the portions of the shareddata set may include a discrete constituent, such as an image, aphotograph, video, sound recording, a biometric input, or another suchdiscrete constituent.

In some embodiments, the shared data set may include two or moretransitory identities of one of the computing devices. For example, asdescribed above, the first computing device may generate a series oftransitory identities over time and may send the transitory identitiesto the second computing device in the normal conduct of securedcommunications using methods described herein. The second computingdevice may store the transitory identities generated by and receivedfrom the first computing device. Thus, in some embodiments the shareddata set may include the first computing device's transitory identitiesreceived over time during secured and/or authenticated communications.In some embodiments, the shared data set may include two or moretransitory identities of the second computing device.

The shared data set 300 a may include one or more portions, such asportions 302 a, 304 a, and 306 a. Each of the portions 302 a, 304 a, and306 a may include one or more elements. For example, portion 302 a mayinclude elements 320 a and 322 a, portion 304 a may include element 324a, and portion 306 a may include elements 326 a and 328 a. In someembodiments, the portions 302 a, 304 a, and 306 a may each be atransitory identity that was generated by a computing device (e.g., oneor more of the computing devices 102, 104, 106, and 108). In someembodiments, the portions 302 a, 304 a, and 306 a may include discreteconstituents, such as photographs, sound recordings, fingerprints,biometric data, or other discrete portions.

In some embodiments, the shared data set 300 a may be built up overtime. For example, a first computing device (e.g., the computing device102, 104) may generate a plurality of transitory identities over time,store a copy of each transitory identity, and may send a copy of eachtransitory identity to a second computing device (e.g., the computingdevice 108), thereby providing the first computing device and the secondcomputing device with a shared data set made up of the transitoryidentities of the first computing device. In some embodiments, thesecond computing device may perform similar operations, obtainingtransitory identities and providing its transitory identities to thefirst computing device. In some embodiments, the first and secondcomputing devices may combine the shared transitory identities from eachof the first and second computing devices to generate the shared dataset. In some embodiments, the first and second computing devices mayeach compile two discrete shared data sets, made up of transitoryidentities of the first computing device, and transitory identities ofthe second computing device, respectively.

In some embodiments, the shared data set 300 a may be built up over timeby one computing device and then shared with another computing device.For example, the computing device 108 may receive data inputs over time(e.g., the data inputs 140). The data inputs may include one or morediscrete constituents, such that the computing device 108 may build up adata set of the data inputs over time. The computing device 108 may thenshare or send the data set with another computing device (e.g., thecomputing device 102, 104, 106).

In various embodiments, the elements 320 a-328 a may include informationthat enables the identification or indexing of each element within aportion. For example, an element may include information identifying alocation, position, and/or time of the element within its portion, orany other information that allows the indexing or identification of eachselected element.

In various embodiments, the portions 302 a-306 a and/or the elements 320a-328 a may include data from which one or more relationships to atleast one other data element may be determined. For example, theportions 302 a-306 a and/or the elements 320 a-328 a may be associatedwith a timestamp. As another example, portions and/or elements may beassociated with a variety of data, such as a location, a position, acolor, a pitch, a frequency, a biometric aspect, or another aspect ofthe portion and/or element. The relationship between the two or moreelements may include a comparative difference between the two or moreelements, such as a time difference, a location difference, a positionaldifference, a color difference, a pitch difference, a frequencydifference, a biometric difference, or another difference.

As another example, the elements 320 a-328 a may have differentpositions or locations within a portion, or between different portions.The elements 320 a-328 a may also be associated with a different time,as well as with different positions or locations, relative to two ormore other elements. In some embodiments, three or more elements maydefine a relationship of one element to two or more other elements. Forexample, the position/location differences among elements 320 a, 322 a,and 324 a may define three angles, angle A, angle B, and angle D.Similarly, the relative position/location and/or time differences amongelements 320 a, 322 a, 324 a, 326 a, and 328 a may define additionalangles, angles C, E, F, G, H, I, and J. In various embodiments, arelationship may be a relative difference in time, space, distance, oranother informational difference, within a portion, among or betweenportions, and/or within the shared data set 300 a.

FIGS. 3B-3E illustrate exemplary shared data sets 300 b, 300 c, 300 d,and 300 e. A shared data set may include one or more of a variety oftypes of data, and the examples illustrated in FIGS. 3A-3D are intendedto illustrate the variety of data types and not as limitations.

For example, the shared data set 300 b may include fingerprints 302 b,304 b, and 306 a. The fingerprints 302 b-306 b may be captured, forexample, by a biometric scanning device such as a fingerprint scanner.The fingerprints 302 b-306 b may be captured over time, such that thefingerprints 302 b-306 b each constitute a portion of the shared dataset 300 b. A processor of a computing device (e.g., the computingdevices 102-108) may select elements from the portions (e.g., thefingerprints 302 b-306 b) of the shared data set 300 b, such as elements320 b-338 b. In some embodiments, the elements 320 b-338 b may includefingerprint minutiae. The elements 320 b-338 b may include informationthat enables a processor of a computing device to identify or index eachelement within a portion (e.g., within one of the fingerprints 302 b-306b), such as information identifying a location or position of theelement within its portion. Further, each portion may be associated witha timestamp or another time element.

The portions (e.g., the fingerprints 302 b-306 b) and/or the elements320 b-338 b may include data from which one or more relationships to atleast one other data element may be determined, such as position,location, and/or time information. In some embodiments, the portionsand/or elements may include data from which one or more relationshipsamong the elements may be determined. In some embodiments, therelationships may be based on one or more comparative differencesbetween or among the elements.

As another example, the shared data set 300 c may include soundrecordings 302 c, 304 c, and 306 c. The sound recordings may becaptured, for example, by a microphone or similar device, or the soundrecordings may be received electronically by a processor of a computingdevice (e.g., the computing devices 102-108) from such a device. Thesound recordings 302 c-306 c may be captured over time, and may includeor be associated with time information. Each of the sound recordings 302c-306 c may constitute a portion of the shared data set 300 c.Additionally, or alternatively, a single recording (e.g., one of 302 c,304 c, or 306 c) may be divided into portions, for example, portions ofa certain time duration, portions divided by frequency range, portionsdivided by amplitude ranges, and other divisions.

A processor of a computing device may select elements from the portionsof the sound recordings 302 c-306 c, such as elements 320 c-330 c. Theelements 320 c-330 c may include information that enables theidentification or indexing of each element within a sound recording,such as information identifying a location or position of the elementwithin its portion. Each element 320 c-330 c may be associated withtimestamp or another time element and/or other information, such asfrequency, a pitch, and amplitude, a rate of attack, a rate of decay, aduration of sustain,

The portions (e.g., the one or more sound recordings 302 c) and/or theelements 320 c-330 c may include data from which one or morerelationships to at least one other data element may be determined, suchas position, location, and/or time information. In some embodiments, theportions and/or elements may include data from which the processor of acomputing device may determine one or more relationships among theelements. In some embodiments, the relationships may be based on one ormore comparative differences between or among the elements.

As another example, the shared data set 300 d may include images 302 d,304 d, and 306 d. The images 302 d-306 d may be of, for example, a faceas illustrated in FIG. 3D, but in various embodiments the images 302d-306 d may be any images. The images 302 d-306 d may be captured, forexample, by a camera or another image receiving device. The images 302d-306 d may be captured over time, such that the images 302 d-306 d eachconstitute a portion of the shared data set 300 d. A processor of acomputing device (e.g., the computing devices 102-108) may selectelements from the portions (e.g., the images 302 d-306 d) of the shareddata set 300 d, such as elements 320 d-336 d. For example, the processorof the computing device may select the elements 320 d-336 d using afacial recognition or other similar system. The elements 320 d-336 d mayinclude information that enables a processor of a computing device toidentify or index each element within a portion (e.g., within one of theimages 302 d-306 d), such as information identifying a location orposition of the element within its portion. Further, each portion may beassociated with a timestamp or another time element.

The portions (e.g., the images 302 d-306 d) and/or the elements 320d-336 d may include data from which one or more relationships to atleast one other data element may be determined, such as position,location, and/or time information. In some embodiments, the elements 320d-336 d may be associated with image information, such as color, tint,hue, grayscale, RGB information, Pantone color number, digital colorcode (e.g., hypertext markup language color code), saturation,brightness, contrast, or other image information. In some embodiments,the portions and/or elements may include data from which one or morerelationships among the elements may be determined. In some embodiments,the relationships may be based on one or more comparative differencesbetween or among the elements. In some embodiments, the comparativedifferences may include differences in image information, includingrelative, linear, and/or numerical differences in information indicatingcolor, tint, hue, etc.

As another example, the shared data set 300 e may include one or morebiometric data units or constituents, such as DNA samples 302 e, 304 e,and 306 e. Biometric data may be captured by an appropriate scanner orcapture device and received by a processor of a computing device (e.g.,the computing devices 102-108). The biometric data may be captured overtime, and may include or be associated with time information. The shareddata set 300 e may include two or more biometric data constituents orunits, each of which may constitute a portion of the shared data set(e.g., two or more discrete biometric samples). Additionally oralternatively, a biometric sample may be divided into portions, whichdivisions may be determined based on the information available in thebiometric sample. For example, the DNA samples 302 e, 304 e, and 306 emay be divided into portions of a certain base-pair length or number, acertain length of the DNA backbone, by type of nucleotide (e.g.,adenine, guanine, cytosine, or thymine), by type of base pair (e.g.,adenine-thymine, cytosine-guanine), or another division.

A processor of a computing device may select elements from the portionsof the biometric data unit 300 e, such as elements 320 e-330 e. Theelements 320 e-330 e may include information that enables theidentification or indexing of each element within a biometric data, suchas information identifying a location or position of the element withinits portion, such as a position along the DNA strand 302 e. Each element320 e-330 e may be associated with timestamp or another time element.

The portions (e.g., the one or more biometric data units 302 e) and/orthe elements 320 e-330 e may include data from which one or morerelationships to at least one other data element may be determined, suchas position, location, and/or time information. In some embodiments, theportions and/or elements may include data from which the processor of acomputing device may determine one or more relationships among theelements. In some embodiments, the relationships may be based on one ormore comparative differences between or among the elements.

FIG. 4 illustrates graphically an overall method 400 for transformingany of a variety of files for efficient or encrypted transmission bymatching streams of bits within the files to portions of an RCD andgenerating a rule set for locating the matching portions of the RCD sothat the rule set can be transmitted to a recipient.

Referring to FIG. 4, a file 402 to be transmitted may be received by acomputing device that implements a rule set generator 406 according tovarious embodiments. The rule set generator may receive the raw data ofthe file 402 as a string of bits 404. The rule set generator may comparethe file bit string 404 to strings of bits within the RCD 408 to findlong strings of matching bits. This process may be accomplished usingany of a variety of algorithms. For example, the rule set generator 406may read in bit strings 404 while matching the bits to portions of theRCD 408 and continue to do so until a match in the RCD is no longerfound. Thus, the longest matching bit string appearing in the RCD 408may be identified by the rule set generator 406.

When the longest matching string is identified, the rule set generator406 may generate a rule 410 that will enable a recipient computingdevice to locate the string within the same RCD 408 (i.e., a copy of theRCD stored in memory of the recipient computing device). The rules 410for locating matching bit strings may depend upon the organization ofthe RCD 408. A variety of RCD structures are described above, but asimple example is illustrated in FIG. 4 in which the RCD 408 structuredas a table with horizontal and vertical indices. Using this example RCD408, the portion matching the file bit string 604 begins at theintersection of vertical index “E” and horizontal index “k” and is 12bits long. Thus the example rule i is “Ek12”. This rule for locating thematching bit string is intended to be illustrative, and not limit theclaims in any way to a particular form of indexing or locating bitstrings within an RCD.

As the rule set generator 406 identifies (or generates) rules 410 forlocating a long bit string within the RCD 408, the rules may beaccumulated in a rule buffer 412, and ultimately stored as a set ofrules in memory (e.g., the rule set 414) that can then be transmitted toa receiver computing device to which the file 402 is to be transmitted.In some embodiments, if the matched bit string in the RCD is longer thanthe length of the rule, the bit string itself may be used as the rule,such as with a flag or a symbol indicating that a particular rule is thebit string. Once the file 402 has been matched to the RCD and rule setsgenerated, the rule sets may be transmitted using any form ofcomputer-to-computer communication protocol and network. In someembodiments, the rule sets may be transmitted once the file 402 has beencompletely matched to the RCD. In some embodiments, a group of rule sets414 may be transmitted when the rule set buffer is full, or is filled toa threshold amount of data. Thus, in some embodiments the file 402 doesnot need to be completely matched to the RCD before a rule set or rulesets are sent to the receiver computing device. Further, unless the RCD408 is known to the public, the transmission of only the rule setprovides effective encryption because a party intercepting or copyingthe received rule set transmission will be unable to reconstruct thefile. Thus, the rule set may be transmitted using any form ofcommunication network protocol without further encryption whileachieving a high degree of security. The security of such transmissionsmay be further enhanced by transforming the RCD 408 using variousembodiments described above, such as shifting the data in the RCD by aparticular length, line or row.

Thus, in the method illustrated in FIG. 4, a computing device receivesand transforms an input file through a series of processor operationsreferencing an RCD 408 stored as a memory file into a rule set thatessentially encodes the file to be sent as a series of rules that thereceiving computing device can use to reconstruct the file referencingthe same RCD stored in the device's local memory.

FIG. 5 graphically illustrates a method 500 by which a computing devicereceiving a transmission of a rule set that is generated according tothe method 400 and having the same RCD 408 stored in an available memorycan quickly reconstruct the original file 402.

The receiving computing device may receive a transmission (e.g., viaemail, Internet, SMS, etc.) of a rule set 502 that includes the sequenceof rules generated as illustrated in FIG. 4. The rule set 502 may bereceived by a receiving system that properly orders the received rulesets for provision to the rule set reader 506 (e.g., to correct forpacket reordering and the like). As an illustration, the rule set mayinclude a particular Rule i “Ek12” for locating a particular string ofbets within the RCD 408. A rule set reader 506 executing within thecomputing device may receive individual rules 504 and use each rule tolook up the corresponding bit string within the RCD 408. In theillustrated example in which the RCD 408 is a tabular data file havingvertical and horizontal indexes, the rule “Ek12” enables the rule setreader 506 to identify a string of bits beginning at the intersection ofhorizontal index “E” and vertical index “k” and extending for 12 bits(i.e., “010110100100”). This output 510 may be temporarily stored in abit buffer 512 adjacent to a previously obtained bit string.Periodically data held within the bit buffer 512 may be copied to a datafile 514 ready for rendering storage, display or other use. In thismanner, as each rule is used by the rule set reader 506, the originalfile (i.e., 402) may be reconstructed at the raw binary data level.

Thus, in the method 500 illustrated in FIG. 5, a computing devicereceives a rule set by any of a variety of communication networks andprotocols, uses each rule to look up a corresponding string of bitswithin an RCD 408 stored as a memory file, and accumulates theidentified bit strings into a reconstruction of the original file at thebinary data level.

FIG. 6 illustrates algorithms or methods 600 that may be implemented ona first computing device (CD1) sending a file to a second computingdevice (CD2) using the techniques illustrated in FIGS. 4 and 5 anddescribed above. With reference to FIGS. 1-6, the algorithms or methods600 may be implemented by one or more processors (e.g., 202) in each ofthe first and second computing devices each with access to memorystoring a synchronized RCD.

In order to transmit a file using various embodiments, the firstcomputing device will synchronize and RCD with the second computingdevice to which the file is to be transmitted. As described above,various methods may be used to either provide an RCD to the secondcomputing device or synchronize an RCD based on files that are shared inboth computers and rules for transforming or otherwise randomizing theRCD in each computer. As a nonlimiting example, the first computingdevice may generate or obtain an RCD in block 602 a that will be used ingenerating the rule set for transmitting the file. In some embodiments,the RCD may be stored in memory of both computing devices, and obtainingthe RCD in block 602 a may merely involve accessing the file in memory.In some embodiments, the RCD may be stored in memory of both computingdevices, and obtaining the RCD in block 602 a may involve accessing thefile in memory in performing a transformation, translation or othermanipulation of the RCD as described previously. In some embodiments,the RCD may be a one-time data set to be used for transmissions of asingle file or set of files to the second computing device, an exampleof which is described below with reference to FIG. 7. In someembodiments, the RCD may be obtained from the second computing device ina data exchange in blocks 604 a and 604 b as described below.

In block 604 a, the first computing device may transmit the RCD to thesecond computing device, transmit information (e.g., rules fortransforming the RCD) to the second computing device to enablegeneration or synchronization the RCD, or receive the RCD from thesecond computing device.

Similarly, the second computing device may optionally generate or obtainthe RCD in block 602 b and communicate with the first computing devicein block 604 b to synchronize the RCD, such as by receiving the RCD fromthe first computing device, receiving information (e.g., rules fortransforming the RCD) for generating the RCD, or transmit to the firstcomputing device an RCD generated in block 602 b.

In blocks 606 a and 606 b the first and second computing device maystore or otherwise make available the synchronized RCD for use in therest of the method 600. In some embodiments, this may simply involvestoring rules or an algorithm for manipulating either the RCD or rulesets used for locating bit strings within the RCD.

As described above, the operations of synchronizing and storing the RCDon the first and second computing devices may be performed in advance oftransmitting particular file or files. For example, the first and secondcomputing devices may exchange or synchronize an RCD that is used forall communications between the two devices. As another example, thefirst and second computing devices may use files that are stored on bothdevices (e.g., default image files), and merely agree on the particulardata files that are going to serve as the RCD.

In block 608, the processor of the first computing device may receive amessage or file to the second computing device. For example, a user ofthe first computing device may type a message to be transmitted in asecure manner to the second computing device. As another example, a usermay identify one or more files stored on the first computing device(e.g., photographs, audio files, etc.) that the user wants transmittedto the second computing device.

In optional block 610, the processor of the first computing device maytransform the RCD and generate a rotation rule as described above forvarious embodiments. This optional transformation or modification of theRCD may be performed to ensure that the communication of the file orfiles to the second computing device will be secure (i.e., receivableonly by the second computing device). This operation may be optionalbecause the RCD may be randomized or transformed as part of theoperation of synchronizing the RCD in blocks 604 a and 604 b asdescribed above. Also, this operation may be optional when there is noneed to secure the communication of the file or files, such as when themethod 600 is being used to exploit the communication efficiency enabledby the method (e.g., to send a large file using email, SMS or othernon-streaming communication method).

In block 612, the processor of the first computing device may select thebeginning (e.g., first bit) of the raw binary data of the message orfile(s) to be transmitted as a starting point of the process ofconverting to a rule set linked to the RCD.

In block 614, the processor of the first computing device may begincomparing a sequence of bits of the raw binary data beginning from theselected starting point to the RCD to identify a long matching bitstring that appears within the RCD data. As described above withreference to FIG. 4, this may be accomplished by using a rule setgenerator application to read in a string of bits from the message orfile so long as matches to the string of bits can be located in the RCD.A long string of bits may be identified when an additional bit cannot bematched to a bit string within the RCD or the length of the bit stringreaches a preset maximum or threshold length.

Once a long string of bits is identified in block 614, the processor ofthe first computing device may generate a rule for locating orrecovering the string of bits within/from the RCD in block 616. The rulemay be generated using any of a variety of methods, including methodsdescribed above, depending upon the data structure of the RCD.

In block 618, the processor may store the generated rule in a rule setfile in sequence.

In determination block 620, the processor may determine whether theentire message or file(s) has/have been compared to the RCD.

In response to determining that the entire message or file(s) has/havenot been compared to the RCD (i.e., determination block 620=“No”), theprocessor may select the bit within the message or file(s) following thelast bit in the previously matched bit string as the starting point forthe next round of comparison in block 622, and then compare the sequenceof bits of the raw binary data beginning from the newly selectedstarting point to the RCD to identify a long matching bit string thatappears within the RCD data in block 614 as described above. Thus, theoperations of matching strings of bits to the RCD to identify longstrings of bits and rules for finding those long strings in the RCDuntil the entire message or file(s) has/have been compared to the RCD.

In response to determining that the entire message or file(s) has/havebeen compared to the RCD (i.e., determination block 620=“Yes”), theprocessor may transmit the generated rule set generated in blocks612-622 and, optionally, the transformation rule generated in block 610,to the second computing device in block 624. As the information in therule set and the rotation rule are useable only by a computing devicepossessing the synchronized RCD, this information may be transmitted tothe second computing device using any communication network and protocolwithout encryption. Additionally, by linking long strings of bits toRCD-lookup rules that are relatively small, the method 600 may enablethe first computing device to relay large messages or files to thesecond computing device using communication methods that have limitedbandwidth or a small maximum file size. Further, the rule set may bebroken into separate messages that are transmitted within message sizelimits. As noted above, in some embodiments, a group of rule sets may betransmitted when the rule set buffer is full, or is filled to athreshold amount of data. Thus, in some embodiments the message or fileto be conveyed to the second computing device does not need to becompletely matched to the RCD before a portion of the rule set or rulesets are sent to the second computing device.

In block 630, the second computing device may receive the rule set and,optionally, the transformation rule from the first computing device.

In optional block 632, the processor of the second computing device mayuse the received transformation rule to transform or adjust the RCD inthe same manner as the RCD used in generating the rule set (i.e., theresult of transforming/adjusting the RCD in optional block 610).

In block 634, the processor of the second computing device may selectthe first rule within the rule set.

In block 636, the processor may use the selected rule to obtain thecorrelated bit string from the RCD. As described with reference to FIG.5, the processor may perform this operation using a rule set readerapplication or software to apply the information in the rule to identifythe sequence of bits within the RCD and copy that bit string.

In block 638, the processor of the second computing device may add theobtained bit string to a rendering bit buffer or memory file in sequencein block 638. In this operation, the processor may store the bit stringcopied from the RCD into the buffer or memory file adjacent to (i.e.,concatenated with) the previously stored bit string.

In determination block 640, the processor of the second computing devicemay determine whether there is another rule within the rule set to beapplied.

In response to determining that there is another rule within the ruleset to be processed (i.e., determination block 640=“Yes”), the processormay select the next rule within the rule set in block 642, and use thisselected rule to obtain the bit string from the RCD in block 636 andproceed with blocks 638-642 until all rules within the received rule sethave been processed.

In response to determining that all rules within the rule set have beenprocessed (i.e., determination block 640=“Yes”), the processor may storeand/or render the message or file(s) on the second computing deviceusing a conventional application appropriate for the message or file(s)in block 644. For example, if the transmitted file is a photograph, thephotograph may be rendered on a display of the second computing deviceusing a conventional photo rendering application in block 644. Asanother example, if the transmitted file is a text document, thedocument may be rendered on an opened in a word processing applicationon the second computing device in block 644. As another example, if thetransmitted file is a video clip, the video may be rendered on a displayof the second computing device by a video application in block 644.

The method 600 may be used to transmit a wide variety of files, and mayuse a generic RCD, such as any of the various types of RCDs describedabove. However, in some implementations or applications, an RCDgenerated specifically for transmission of particular types of files ordocuments may be more efficient because of a higher incidence of largerepeating strings within it. In such instances, the RCD used in both thefirst and second computing devices may be smaller because bit sequencesincluded within the RCD appear frequently within the files beingtransmitted and less of the data with the RCD is not used in suchtransmissions. An example of such an implementation is the use fortransmitting text-based documents because many words and word sequences(as well as letter sequences) will be repeated across various documents,and therefore large bit sequences can be expected to be repeated.

FIG. 7 illustrates of a method 700 of an example application in which anembodiment is used to securely transmit a number of documents from thefirst computing device to a second computing device. The method 700 maybe implemented by processors (e.g., 202) of the first and secondcomputing devices. In particular, the method 700 may be useful in asituation in which a number of documents need to be transmitted securelybetween the first and second computing devices that have not previouslyexchanged an RCD. In the method 700, the processors may performoperations of like numbered blocks of the method 500 as described withreference to FIG. 5.

In block 702, a user of the first computing device may select aparticular document to serve as the source of an RCD. Such a documentmay be of sufficient length so that it contains a large number of wordsand word sequences likely to appear in the other documents that will besent as rule sets based upon the RCD generated from that document. Insome embodiments, the document may be sent to the second computingdevice in the open (i.e., and not encrypted). For example, in asituation in which a large number of proprietary documents (e.g., a duediligence package for a corporate or financial transaction) will betransmitted to the second computing device using the method 700, asuitable document to serve as the RCD could be the nondisclosureagreement by which the parties controlling the first and secondcomputing devices have agreed to exchange the documents confidentially.As another example, a public document (e.g., section of a newspaper, aportion of a textbook, etc.) may be selected to serve as the RCD inblock 702.

In block 704 a, the processor of the first computing device may transmitthe RCD document to the second computing device, which may receive thedocument in block 704 b. The two computing devices may further exchangeinformation in order to synchronize the RCD between the two devices. Inblocks 706 a and 706 b, the processors of the first and second computingdevices may store the synchronized RCD.

In block 708, the processor of the first computing device may receivethe document or documents to be transmitted to the second computingdevice. Such documents may be loaded in memory and accessed by theprocessor. In some embodiments, the documents may be combined into asingle data file in block 708. In some embodiments, the documents may besequenced for transmission as part of the operations in block 708.

In optional block 710, the processor of the first computing device maytransform the RCD and generate a transformation rule as described abovefor various embodiments. This optional transformation or modification ofthe RCD may be performed to ensure that the communication of thedocuments to the second computing device will be secure (i.e.,receivable only by the second computing device). This operation may beoptional because the RCD may be randomized or rotated as part of theoperation of synchronizing the RCD in blocks 704 a and 704 b. Also, thisoperation may be optional when the documents are not confidential (i.e.,do not need to be encrypted) and the method 700 is being used to exploitits communication efficiency.

In block 712, the processor of the first computing device may select thebeginning (e.g., first bit) of the raw binary data of the document(s) tobe transmitted as a starting point of the process of converting to arule set linked to the RCD.

In blocks 714-718, the processor of the first computing device mayperform the operations of like numbered blocks of the method 500 asdescribed above to generate a rule for locating long bit strings withinthe RCD that match bit strings within the document(s) to be transmitted.

In determination block 720, the processor may determine whether theentire document or documents has/have been compared to the RCD. In someembodiments, rule sets may be transmitted to the second computing devicebefore all of the documents have been compared to the RCD. For example,the rule sets for documents may be transmitted for a single document orfor a subset of all of the documents. In some embodiments, a group ofrule sets may be transmitted to the second computing device when a ruleset buffer of the first computing device is full, or is filled to athreshold amount of data. Thus, in some embodiments, all of thedocuments do not need to be completely matched to the RCD beforetransmission of a rule set or rule sets to the second computing devicebegins.

In response to determining that the entire document or documentshas/have has/have not been compared to the RCD (i.e., determinationblock 720=“No”), the processor may select the bit within the message orfile(s) following the last bit in the previously matched bit string asthe starting point for the next round of comparison in block 622, andthen compare the sequence of bits of the document(s) raw binary databeginning from the newly selected starting point to the RCD to identifya long matching bit string that appears within the RCD data in block 614as described above. Thus, the operations of matching strings of bits tothe RCD to identify long strings of bits and rules for finding thoselong strings in the RCD until the entire document(s) has/have beencompared to the RCD.

In response to determining that the entire document(s) has/have beencompared to the RCD (i.e., determination block 720=“Yes”), the processormay transmit the rule set generated in blocks 614-622 and, optionally,the transformation rule generated in optional block 710, to the secondcomputing device in block 624. As the information in the rule set andthe transformation rule are useable only by a computing devicepossessing the synchronized RCD, this information may be transmitted tothe second computing device using any communication network and protocolwithout encryption (although any form of encryption may also be appliedto the rule sets for transmission). Additionally, by linking longstrings of bits to RCD-lookup rules that are relatively small, themethod 700 may enable the first computing device to relay largedocuments to the second computing device using communication methodsthat have limited bandwidth or a small maximum file size. Further, therule set may be broken into separate messages that are transmittedwithin message size limits.

In block 630, the processor of second computing device may receive therule set and, optionally, the transformation rule from the firstcomputing device. In blocks 632-642, the processor of second computingdevice may perform the operations of the like numbered blocks of themethod 600 as described to use the rule set to find long bit stringswithin the RCD and generate a concatenated binary data file replicatingthe document(s) being transmitted.

In response to determining that all rules within the rule set have beenprocessed (i.e., determination block 640=“Yes”), the processor may storeand/or open the document(s) on the second computing device using aconventional word processor or document application in block 744.

Various embodiments may similarly be applied to transmitting video andmultimedia, including streaming of movies and similar multimedia files.FIG. 8A illustrates graphically an overall method 800 a for transforminga stream of multimedia image frames for efficient or encryptedtransmission by matching streams of bits within the frames to portionsof an RCD and generating rule sets for locating the matching portions ofthe RCD so that the rule sets can be transmitted to a second computingdevice for rendering of multimedia.

Referring to FIG. 8A, a multimedia file including a stream of imageframes 802 that are to be delivered to receiving devices may be obtainedor received by a computing device that implements a rule set generator806 according to various embodiments. The multimedia file may beformatted in any conventional media data format. For example, the mediafile may be in full fidelity high definition image format in which eachimage frame includes information for each and every pixel. As anotherexample, the media file may be in a high definition (HD) video format.As another example, the media file may be in a digital videobroadcasting (DVB) format such as compliant with the DVB-X standard. Asanother example, the media file may be in the Multimedia MessagingService (MMS) format. As another example, the multimedia file may be inthe multimedia broadcast and multicast system (MBMS) format or theenhanced MBMS (eMBMS) format. As another example, the multimedia filemay be in a compressed video format such as defined in ISO/IEC14496-10/MPEG-4 AVC. Another format of multimedia, including multimediaformats yet to be defined, may be used with various embodiments. Somemedia formats may not include complete image data for each frame, suchas compressed video formats that intersperse information regardingchanges in portions or particular pixels from one frame to the nextbetween full image frames. For ease of reference, the term “image frame”is used to refer to the information included in a multimedia fileassociated with a particular frame of video as well as associated audio,even if that information is not a complete, standalone image. Thus, thevarious embodiments enable conversion and delivery of multimediaregardless of the format of the input multimedia file.

The rule set generator may receive the raw data of each image frame 802as a string of bits 804. The rule set generator may compare the file bitstring 604 to strings of bits within the RCD 808 to find long strings ofmatching bits. This process may be accomplished using any of a varietyof algorithms. For example, the rule set generator 806 may read in bitstrings 604 while matching the bits to portions of the RCD 808 andcontinue to do so until a match in the RCD is no longer found. Thus, thelongest matching bit string appearing in the RCD 808 may be identifiedby the rule set generator 806. In some embodiments, this comparison ofbit string's 604 to the RCD may be performed until a maximum bit stringlength is reached. While the process of matching the raw bit string ofimage files to the RCD may be time-consuming, the various embodimentsare most useful in applications in which there is sufficient time totransform large video files into relatively small rule set files forlater transmission.

When a long matching string is identified, the rule set generator 806may generate a rule 810 that will enable a recipient computing device tolocate the string within the same RCD 808. The rules 810 for locatingmatching bit strings may depend upon the organization of the RCD 808. Avariety of RCD structures are described above, but a simple example isillustrated in FIG. 8A in which the RCD 808 structured as a table withhorizontal and vertical indices. Using this example RCD 808, the portionmatching the file bit string 604 begins at the intersection of verticalindex “E” and horizontal index “k” and is 12 bits long. Thus, theexample rule i is “Ek12”. This rule for locating the matching bit stringintended to be illustrative, and not limit the claims in any way to aparticular form of indexing or locating bit strings within an RCD.

As the rule set generator 806 identifies rules 810 for locating a longbit string within the RCD 808, the rules may be accumulated in a ruleset buffer 812, and ultimately stored as a set of rules in memory 814that can be transmitted to a computing device to which the media file802 is to be provided. The rule set may be transmitted using any form ofcomputer-to-computer communication protocol and network, includingcommunication protocols not otherwise suitable for communicatingmultimedia files. Further, unless the RCD 808 is known to the public,the transmission of only the rule set provides effective protections fordigital rights because a party intercepting or copying the received ruleset transmission will be unable to reconstruct the multimedia file.Thus, digital rights management (DRM) requirements can be satisfiedwhile transmitting the multimedia files using any form of communicationnetwork protocol without encryption. The effectiveness of the DRMprotections may be further enhanced by transforming the RCD 808 usingvarious embodiments described above.

Thus, in the method 800 a illustrated in FIG. 8A, a computing devicereceives and transforms an input multimedia file through a series ofprocessor operations referencing an RCD 808 stored as a memory file,into one or more rule sets that essentially encodes the image frames andaudio as a series of rules that a receiving computing device can use toreconstruct the file referencing the same RCD stored in the device'slocal memory.

Referring to FIG. 8B, the method 800 b involves a computing device suchas a server of a media delivery service transforming an input multimediafile, such as a movie or similar file, through a series of processoroperations referencing a media-specific RCD 830 stored as a memory file,into a series of rules sets that essentially encodes the image framesand audio as a series of rules that a receiving computing device can useto reconstruct the file referencing the same RCD stored in the device'slocal memory. The difference between the method 800 a illustrated inFIG. 8A and the method 800 b in FIG. 8B is that the RCD is speciallycreated to include primarily long bit strings that have been determinedto be present in many or most multimedia files, such as movies. FIG. 14below illustrates an example of a method for generating suchmedia-specific RCDs. Generally, such a media-specific RCD may beregarded as a database of long bit strings indexed so that the index maybe used as a substitute (e.g., as a rule) for the corresponding bitstring by a computing device storing the same media-specific RCD.

FIG. 8B illustrates simple example in which the RCD 830 structured as anindexed table with each row or file associated with a single index value(illustrated A-P). The potential advantage of using a media-specific RCD830 is that the various bit strings can be treated as data fields in anindexed database, thus simplifying the format of rules used to identifyparticular bit strings. Using this example RCD 1108, the portionmatching the file bit string “010110100100” 604 has the index value “A”.Thus, the example Rule i is “A”. This rule for locating the matching bitstring is intended to be illustrative, and not limit the claims in anyway to a particular form of indexing or locating bit strings within anRCD.

In view of the ability to use an index rule for a media-specific primaryRCD when a secondary RCD is used to obfuscate primary rules, short bitstrings of a length equal to the index binary bit length may be includedwithin the primary RCD. For bit strings in the multimedia file that areshorter than the index binary bit length, the data itself may be thecorresponding rule, such as with a most significant bit serving as aflag to indicate whether the rest of the index value is a data string ora rule mapping to the primary RCD. For example, if the primary RCDincludes no more than 32,768 entries, a two-byte index can be usedleaving the most significant bit available for use as a flag forindicating raw bit string data (e.g., a “0” in the most significant bit)or an RCD lookup rule (e.g., a “1” in the most significant bit). Thus,in this non-limiting example, the primary rule set generator 806 that isunable to match a bit string longer than 16 bits to the RCD would outputa 16 bit rule in which the first bit is “0” and the rest of the bits inthe index are the first 15 bits of the unmatched bit string. Becausesuch data rules will be interspersed with rules mapped to long bitstrings, this transmission of raw data should not compromise the DRMprotections provided by various embodiments.

FIG. 9A graphically illustrates a method 900 a by which a computingdevice receiving a transmission of one or more rule sets generatedaccording to the method 800 a and having the same RCD 808 stored in anavailable memory can quickly reconstruct and render the originalmultimedia file 802 using any conventional media rendering application920.

A media receiver, transceiver or application 902 of a computing devicemay receive a transmission (e.g., via email, Internet, SMS, etc.) of oneor more rule sets 904 that includes the sequence of rules generated asillustrated in FIG. 8A. In some embodiments, the rule sets may bebuffered 906 (i.e., temporarily stored) so that the rules may beindividually processed by a rule set reader 910 while the mediareceiver, transceiver or application 902 continues to receive rules, asin a media streaming implementation. As an illustration, a rule set mayinclude a particular Rule i “Ek12” for locating a particular string ofbits within the RCD 808. A rule set reader 910 executing within thecomputing device may receive individual rules 908 and use each rule tolook up the corresponding bit string within the RCD 912. In theillustrated example in which the RCD 912 is a tabular data file havingvertical and horizontal indexes, the rule “Ek12” enables the rule setreader 906 to identify a string of bits 914 beginning at theintersection of horizontal index “E” and vertical index “k” andextending for 12 bits (i.e., “010110100100”). This output 914 may betemporarily stored in a bit buffer 916 adjacent to a previously obtainedbit string. Periodically, data held within the bit buffer 916 may becopied to a media data buffer 918 that is configured to queue multimediadata (e.g., multimedia data packets according to the original media dataformat) for rendering by a conventional media rendering application 920.

In embodiments in which a media-specific RCD are used, the receivingcomputing device operates in a similar manner. FIG. 9B illustrates amethod 900 b in which a computing device replicates a multimedia filethat was encoded using a media-specific RCD per the method the method900 a illustrated in FIG. 9A. In the illustrated example, the Rule i ofindex “A” maps to the field in the media-specific RCD 930 including thebit string “010110100100” that the rule set reader 910 may output to abit buffer 916 as described with reference to FIG. 9A.

Thus, in the method 900 a illustrated in FIG. 9A and the method 900 billustrated in FIG. 9B, a computing device receives one or a series ofrule sets by any of a variety of communication networks and protocols,uses each rule to look up a corresponding string of bits within an RCD912 stored as a memory file, accumulates the identified bit strings intomedia play buffer that supports (i.e., provides media data to) aconventional media rendering application. This enables the variousembodiments to be used for transporting multimedia files of any formatusing any conventional communication network or protocol, includingcommunication protocols not suitable for carrying the originalmultimedia data format, to computing devices for rendering using anyconventional multimedia player or application compatible with theoriginal multimedia data format.

FIG. 10 illustrates algorithms or methods 1000 that may be implementedon a first computing device (CD1) sending a multimedia file (e.g.,streaming video) to a subscriber computing device (CD2) using thetechniques illustrated in FIGS. 8A, 8B, 9A, and 9B and described above.With reference to FIGS. 1-10, the algorithms or methods 1000 may beimplemented by one or more servers or other computing devices within amedia delivery service provider and one or more processors (e.g., 202)in a subscriber computing device with access to memory storing asynchronized RCD.

The methods 1000 may be implemented by a media delivery service (e.g.,Netflix, Amazon, Hulu, etc.) for delivering movies and similarmultimedia files to subscribers. To support such deliveries, the mediadelivery service may implement a subscription sign-up method 1002 a bywhich the service provides synchronized one or more synchronized RCDs toa new subscriber computing device, which implements a subscriptionregistration process 1002 b. For example, a server of the media deliveryservice may obtain one or more stored media RCDs in block 1012. SuchRCDs may be of a variety of formats including the examples describedabove. The RCD(s) may be generated by the media delivery service, may beunique to the subscriber computing device, or may be optimized for mediadelivery, such as described in more detail with reference to FIGS.11-14. In block 1014 a, the server may transmit the one or more RCDs tothe subscriber computing device that receives and saves the RCDs inblocks 1014 b and 1016 b, such as during a subscription sign-up. Thisdelivery may use any of a variety of forms, such as providing the RCDsfor download from a website. In block 1016 a, the server may storeinformation regarding the subscriber that will be used in subsequentmedia delivery operations, such as information regarding the particularRCDs that were downloaded to the subscriber computing device.

To prepare a multimedia file for delivery using various embodiments, aserver or other type of computing device of the media delivery serviceprovider may perform operations in method 1004 to transform themultimedia file into one or more rule sets. For ease of reference, thecomputing device used to implement the method 1004 is referred to hereinas a “server,” however, this reference is not intended to be limiting asthe operations may be performed by a workstation, mainframe computer,matrix of personal computers, or other type of computing device.

In block 1018, the server may obtain or access a multimedia file (e.g.,a movie file) for processing. For example, the server may access a moviewithin a server farm of stored movie files.

In block 1020, the server may select the beginning (e.g., first bit) ofthe raw binary data of the media file as a starting point of the processof converting to a rule set linked to the RCD.

In block 1022, the processor of the first computing device, such asusing a rule set generator application, may begin comparing a sequenceof bits of the raw binary data beginning from the selected startingpoint to the RCD to identify a long matching stream that appears withinthe RCD data. As described above with reference to FIGS. 8A and 8B, thismay be accomplished by reading in a string of bits from the multimediafile while so long as matches to the string of bits can be located inthe RCD. A long string of bits may be identified when an additional bitcannot be matched to a string within the RCD or the length of the stringreaches a preset maximum or threshold length.

Once a long string of bits is identified in block 1022, the server maygenerate a rule for locating or recovering the string of bitswithin/from the RCD in block 1024. The rule may be generated using anyof a variety of methods, including methods described above, dependingupon the data structure of the RCD.

In block 1026, the processor may store the generated rule in a rule setfile in sequence.

In determination block 1030, the processor may determine whether theentire multimedia file has been compared to the RCD.

In response to determining that the entire multimedia file has not beencompared to the RCD (i.e., determination block 1030=“No”), the processormay select the bit within the multimedia file following the last bit inthe previously matched bit string as the starting point for the nextcomparison in block 1032, and then compare the sequence of bits of theraw binary data beginning from the newly selected starting point to theRCD to identify a long matching stream that appears within the RCD datain block 1022 as described above. Thus, the operations of matchingstrings of bits to the RCD to identify long strings of bits and rulesfor finding those long strings in the RCD may continue until the entiremultimedia file has been compared to the RCD.

In response to determining that the entire multimedia file has beencompared to the RCD (i.e., determination block 1030=“Yes”), theprocessor may store the rule sets generated in blocks 1020-1032 forlater use in response to a request to play the media file received froma subscriber. By linking long strings of bits to RCD-lookup-rules thatare relatively small, the method 1000 may enable delivery ofmovie-length multimedia files to subscriber computing devices usingcommunication methods that have limited bandwidth or a small maximumfile size. Further, the rule sets may be broken into separate messagesthat are transmitted within message size limits.

The subscriber computing device may perform method 1006 b in order todownload and render a multimedia file (e.g., a movie) from the mediadelivery service. For example, a processor of the subscriber computingdevice may transmit a request for a particular media file to the mediadelivery service in block 1040 using any of a variety of communicationmethods (e.g., accessing a website, transmitting a request via anapplication, sending an email, etc.).

The media delivery server may respond to a request for a multimedia fileby executing operations of method 1006 a. In block 1042, the server mayreceive the request of the media file from the subscriber computingdevice, and access data for delivering the multimedia file to thesubscriber from memory. This may involve accessing information regardingthe particular subscriber computing device, such as a subscriberidentifier, information regarding the previously downloaded RCDs, andinformation related to the subscriber's account.

In optional block 1044, the server may generate a transformation rulefor transforming or otherwise randomizing the RCD, and apply thetransformation rule to the rule sets for the requested multimedia filein optional block 1046. In some embodiments, the rule sets for theparticular the media file previously generated in method 1004 may bealtered consistent with how the transformation rules generated in block1044 will cause the subscriber RCDs to be modified. In this manner therule sets sent to the subscriber computing device will only work inidentifying bit streams of the particular multimedia file using thesubscriber's RCDs after the RCDs has/have been transformed according tothe transformation rule. Thus, the rule sets transmitted to eachsubscriber computing device for a given media file may be different.These operations may be considered optional because protecting digitalrights may be accomplished using other DRM methods, such as encryptedcommunication protocols, direct network connections, etc.

In block 1048, the server may begin streaming the stored and, optionallytransformed, rule sets for the requested media file to the subscribercomputing device. Again, the delivery of the rule sets to the subscribercomputing device may use any known or for future form of datacommunication suitable for streaming data delivery. Examples includestreaming data via Internet HTTP protocol, mobile streaming mediaprotocols, etc.

In optional block 1050, the subscriber computing device may receive thetransformation rule from the media service provider server, and applythe rule to transform the RCD accordingly in optional block 1052. Bytransforming the RCD in this manner, the subsequently received ruleswill correspond to the correct bit strings of the selected media file.

In block 1054, the subscriber computing device may begin receiving ruleswithin the rule set and, optionally, the transformation rule from thefirst computing device.

In block 1056, the processor of the subscriber computing device mayselect the first rule within the rule set.

In block 1058, the processor may use the selected rule to obtain thecorrelated bit string from the RCD. As described with reference to FIGS.9A and 9B, the processor may perform this operation using a rule setreader application 910 or software to apply the information in the ruleto identify the sequence of bits within the RCD and copy that bitstring.

In block 1060, the processor of the subscriber computing device may addthe obtained bit string to a rendering bit buffer or memory file insequence. In this operation, the processor may store the bit stringcopied from the RCD into the buffer or memory file adjacent to (i.e.,concatenated with) the previously stored bit string.

In determination block 1062, the processor may determine whether enoughdata has been received and added to the rendering buffer to enablerendering of a complete frame of the original media file. Thisdetermination may depend upon the amount of data that appears in thebuffer, or the presence within the data of a flag or demarcation dataindicating the start or end of a frame of data as may appear in theoriginal media file format.

In response to determining that enough data appears in the renderingbuffer for a media frame (i.e., determination block 1062=“Yes”), thedata within the rendering buffer may be passed to a media application inblock 1064. Again, the media application may be any known orconventional video rendering application that is capable of renderingthe original media file format. Many such media applications include abuffer or memory queue for accepting and temporarily streaming data asdata packets are received and assembled so that a constant stream ofmedia data can be provided to a rendering process. The operations inblock 1064 may direct data to any such buffer or memory queue, therebysupporting interoperability with a media rendering application.

In response to determining that insufficient data to support rendering aframe has been received in the rendering buffer (i.e., determinationblock 1062=“No”), or before or after buffer data is passed to the mediaapplication in block 1064, the processor of the subscriber computingdevice may determine whether there is another rule within the rule setto be applied in determination block 1066. In this embodiment addressingthe rendering of streaming media files, this determination may beequivalent to determining whether the media file is over.

In response to determining that there is another rule within the ruleset to be processed (i.e., determination block 1066=“Yes”), theprocessor may select the next rule within the rule set in block 1068,and use this selected rule to obtain the bit string from the RCD inblock 1058 and proceed with blocks 1060-1068 until the subscribercomputing device stopped receiving streamed rule sets and the full mediafile has been rendered.

In response to determining that there are no more rules within the ruleset to process (i.e., determination block 1066=“No”), the processor mayend the method.

As described above with reference to FIG. 8B, the transmission ofcertain types of multimedia files, such as movies, may be facilitated bygenerating a media-specific RCD that includes long bit strings that havea high probability of appearing in the multimedia files. FIGS. 11A-12illustrate the delivery of multimedia files using such media-specificRCDs and a subscriber RCD to provide additional DRM. FIG. 13Aillustrates methods for encoding and rendering multimedia files usingsuch media-specific RCDs and subscriber RCDs.

Referring to FIG. 11A, a multimedia file including a stream of imageframes 802 that are to be delivered to receiving devices may be obtainedor received by a computing device that implements a primary rule setgenerator 1106 according to various embodiments. The primary rule setgenerator 1106 may be the same as or similar to the rule set generator806 described with reference to FIGS. 8A and 8B. The multimedia file maybe formatted in any conventional media data format. For example, themedia file may be in full fidelity high definition image format in whicheach image frame includes information for each and every pixel. Asanother example, the media file may be in a high definition (HD) videoformat. As another example, the media file may be in a digital videobroadcasting (DVB) format such as compliant with the DVB-X standard. Asanother example, the media file may be in the Multimedia MessagingService (MMS) format. As another example, the multimedia file may be inthe multimedia broadcast and multicast system (MBMS) format or theenhanced MBMS (eMBMS) format. As another example, the multimedia filemay be in a compressed video format such as defined in ISO/IEC14496-10/MPEG-4 AVC. In the other format of multimedia, includingmultimedia formats yet to be defined, may be used with variousembodiments. Some media formats may not include complete image data foreach frame, such as compressed video formats that intersperseinformation regarding changes in portions or particular pixels from oneframe to the next between full image frames. Again, the term “imageframe” is used to refer to the information included in a multimedia fileassociated with a particular frame of video as well as associated audio,even if that information is not a complete, standalone image. Thus, thevarious embodiments enable conversion and delivery of multimediaregardless of the format of the input multimedia file.

The rule set generator may receive the raw data of each image frame 802as a string of bits 804. The rule set generator may compare the file bitstring 604 to strings of bits within the RCD 830 to find long strings ofmatching bits. This process may be accomplished using any of a varietyof algorithms. For example, the primary rule set generator 1106 may readin bit strings 604 while matching the bits to portions of the RCD 830and continue to do so until a match in the RCD is no longer found. Thus,the longest matching bit string appearing in the RCD 830 may beidentified by the primary rule set generator 1106. In some embodiments,this comparison of bit string's 804 to the RCD may be performed until amaximum bit string length is reached. While the process of matching theraw bit string of image files to the RCD may be time-consuming, thevarious embodiments are most useful in applications in which there issufficient time to transform large video files into relatively smallrule set files for later transmission.

When a long matching string is identified, the primary rule setgenerator 1106 may generate a rule 1110 that will enable a recipientcomputing device to locate the string within the same RCD 830. The rules1110 for locating matching bit strings may depend upon the organizationof the RCD 830. A variety of RCD structures are described above, but asimple example is illustrated in FIG. 8B in which a media-specific RCD830 is structured as an indexed table with each row or file associatedwith a single index value (illustrated A-P). The potential advantage ofusing a media-specific RCD 830 is that the various bit strings can betreated as data fields in an indexed data base, thus simplifying theformat of rules used to identify particular bit strings. Using thisexample RCD 830, the portion matching the file bit string 804 has theindex value “A”. Thus, the example rule i is “A”. This rule for locatingthe matching bit string intended to be illustrative, and not limit theclaims in any way to a particular form of indexing or locating bitstrings within an RCD.

In view of the ability to use an index rule for a media-specific primaryRCD when a secondary RCD is used to obfuscate primary rules, short bitstrings of a length equal to the index binary bit length may be includedwithin the primary RCD. For bit strings in the multimedia file that areshorter than the index binary bit length, the data itself may be thecorresponding rule, such as with a most significant bit serving as aflag to indicate whether the rest of the index value is a data string ora rule mapping to the primary RCD. For example, if the primary RCDincludes no more than 32,768 entries, a two-byte index can be usedleaving the most significant bit available for use as a flag forindicating raw bit string data (e.g., a “0” in the most significant bit)or an RCD lookup rule (e.g., a “1” in the most significant bit). Thus,in this non-limiting example, the primary rule set generator 1106 thatis unable to match a bit string longer than 16 bits to the RCD wouldoutput a 16 bit rule in which the first bit is “0” and the rest of thebits in the index are the first 15 bits of the unmatched bit string.Because such data rules will be interspersed with rules mapped to longbit strings, this transmission of raw data should not compromise the DRMprotections provided by various embodiments.

As the rule set generator 1106 identifies rules 1110 for locating a longbit string within the RCD 808, the rules may be accumulated in a ruleset buffer 812.

In this embodiment, in which the media-specific RCD 830 may bestructured as an indexed date piece of frequently appearing long bitstrings, it may be difficult to transform the RCD for purposes ofensuring security or implementing DRM methods. The RCD may be shifted ina simple manner, such as shifting rows or lines, however, such simplemethods may be easy to discover by checking a relatively small number ofshifts until the correct shift is found. Therefore, to provide securityand DRM methods, the rules for finding bit strings within themedia-specific RCD 830 generated by the primary rule set generator 1106may be encoded into secondary rules by a secondary rule set generator1114 using a subscriber RCD 1116. The purpose of the subscriber RCD 1116is to render a rule set for delivery to the subscriber computing devicethat is usable only by that device, thereby protecting the multimediafile from being pirated or copied by intercepting or copying thetransmitted rule set. For ease of reference, rules generated by theprimary rule set generator 1106 are referred to as primary rules 1110,while rules generated by the secondary rule set generator 1114 arereferred to as secondary rules 1118.

Thus, primary rules 1110 generated by the primary rule set generator1106 may be individually compared to a subscriber RCD 1116 by asecondary rule set generator 1114. The secondary rule set generator 1114performs a similar function to the primary rule set generator 1106 inthat the bit string of each primary rule is compared to bit stringswithin the subscriber RCD 1116 to find the longest matching string, andgenerate the secondary rule to enable a receiving computing device tofind the primary rule within a matching subscriber RCD.

Since the length of the primary rules will be limited, the subscriberRCD 1116 may be a smaller database then necessary to serve the functionsof the primary RCD 830. Being small, the subscriber RCD 1116 may beeasier to generate transformation rules that can be applied to thesecondary rule set in the subscriber RCD 1116 than is the case for avery large RCD as in the embodiments illustrated in FIGS. 8A-10.

In the illustrated example, the long bit string 804 of “101101001000” isfound by the primary rule set generator 1106 to match the entry withinthe primary RCD 830 with an index value of “A” for Rule i, which in ASCIis the binary number “10000001.” The secondary rule set generator 1114finds this number “10000001” within the subscriber RCD 1116 at index“Fb”. Since the index for the primary RCD 830 may be a fixed format, alength of the bit string may not be required for the secondary rule asillustrated.

Secondary rules 1118 generated by the secondary rule set generator 1114may be stored as a set of rules in memory 1120 that can be transmittedto a computing device to which the media file 802 is to be provided. Aswith other embodiments, the rule set may be transmitted using any formof computer-to-computer communication protocol and network, includingcommunication protocols not otherwise suitable for communicatingmultimedia files. Further, because the subscriber RCD 1116 may berendered unique to a particular subscriber and media delivery bytransformation, the transmission of only the secondary rule set provideseffective protections for digital rights because a party intercepting orcopying the secondary rule set transmission will be unable toreconstruct the multimedia file. Thus, digital rights management (DRM)requirements can be satisfied while transmitting the multimedia filesusing any form of communication network protocol without encryption.

Thus, in the method 1100 a illustrated in FIG. 11A, a computing devicesuch as a server transforms an input multimedia file, such as a movie orsimilar file, through a series of processor operations referencing aprimary RCD 830 stored as a memory file, into a series of rules setsthat essentially encodes the image frames and audio as a series of rulesthat a receiving computing device can use to reconstruct the filereferencing the same RCD stored in the device's local memory.

FIG. 11B graphically illustrates a method 1100 b according to anotherembodiment in which primary rules are stored in memory for laterdelivery to customers and the generation of secondary rule sets occursat or near the time of transmission. In this embodiment, all theoperations described above with reference to FIG. 11A are performed withthe addition that primary rule sets from the rule set buffer 812 aresaved in a storage for all completed primary rule sets 1122, such as ina large database of a server farm supporting the media delivery service.Then, when a customer requests delivery of a particular multimedia file(e.g., a movie), the corresponding primary rule sets are drawn from thestorage 1122 and processed through the secondary rule set generator 1114as described above to generate secondary rules 1118 that may betemporarily stored and/or streamed to the subscriber in block 1124.Given the smaller and known format of primary rules and smaller size ofthe subscriber RCD, the operations of generating secondary rules may beperformed at the same time as and in parallel with streaming the rulesto the subscriber. Alternatively, a subscriber may request downloadingof a multimedia in advance (e.g., a few minutes, a few hours or a fewdays) of viewing, during which the generation of secondary rule sets maybe performed and temporary stored until the pre-set time of streaming.

This alternative embodiment may enable the use of subscriber RCDs 1116that are unique to a particular subscriber and/or download event. Forexample, a subscriber unique RCD may be generated and stored on thesubscriber's computing device upon registration. Such subscriber uniqueRCDs may be periodically changed (e.g., transformed) or upgraded. Asanother example, an RCD distributed to more than one subscriber may berendered one-time unique through a transformation rule that is sent tothe subscriber's computing device prior to streaming and used by theserver to transform the subscriber RCD 1116 before the process ofgenerating secondary rule sets begins.

Similar to the method 1100 a illustrated in FIG. 11A, the method 1100 billustrated in FIG. 11B involves a computing device such as a servertransforming an input multimedia file, such as a movie or similar file,through a series of processor operations referencing a primary RCD 830stored as a memory file, into a series of rule sets that essentiallyencodes the image frames and audio as a series of rules that a receivingcomputing device can use to reconstruct the file referencing the sameRCD stored in the device's local memory.

FIG. 12 graphically illustrates a method 1200 by which a subscribercomputing device receiving a transmission of secondary rule setsgenerated according to the methods illustrated in FIG. 11A or 11B. Withreference to FIGS. 1-12, the subscriber computing device has a primaryRCD 830 stored in memory that is the same as (or essentially the same asthe primary RCD 830 used in generating primary rule sets in the methodsillustrated in FIG. 11A or 11B. The subscriber computing device also hasa secondary RCD 1116 stored in memory that is the same as (oressentially the same as) the secondary RCD 1116 used in generatingsecondary rule sets in the methods illustrated in FIG. 11A or 11B. Theprimary and secondary RCDs may be stored in an available memory canquickly reconstruct and render the original multimedia file 802 usingany conventional media rendering application 1222.

A media receiver, transceiver or application 1202 of a computing devicemay receive a transmission (e.g., via email, Internet, SMS, etc.) of oneor more secondary rule sets 1204 that include the sequence of secondaryrules 1118 generated as illustrated in FIG. 11A or 11B. In someembodiments, the secondary rule sets may be buffered 1206 (i.e.,temporarily stored) so that the secondary rules 1208 may be individuallyprocessed by a secondary rule reader and primary rule set generator 1210while the media receiver, transceiver or application 1202 continues toreceive rules, as in a media streaming implementation.

As an illustration, a rule set may include a particular Rule i “Fa” forlocating a particular string of bits within the secondary or subscriberRCD 1116. A secondary rule reader and primary rule set generator 1210executing within the computing device may receive individual rules 1208,use each rule to look up the corresponding bit string within thesubscriber RCD 1116, and output the corresponding bit string as aprimary rule 1212. In the illustrated example in which the subscriberRCD 1116 is a tabular data file having vertical and horizontal indexes,the rule “Fa” enables the secondary rule reader and primary rule setgenerator 1210 to identify a string of bits beginning at theintersection of horizontal index “F” and vertical index “a” andextending for the standard length of primary rules (e.g., 12 bits andthus “010110100100” which is the ASCI value for “A” in the illustratedexample). This output of a primary rules may be output to a primary ruleset reader 1214 executing in the computing device.

The primary rule 1212 output of the secondary rule reader and primaryrule set generator 1210 may be received and processed by a primary ruleset reader 1214. In some embodiments, the primary rules 1212 may betemporarily staged or queued in a buffer (not shown) before processingby the primary rule set reader 1214. The primary rule set reader 1214may use each primary rule to look up the corresponding bit string withinthe primary RCD 830, and pass the bit string to a bit buffer 1218. Inthe example illustrated in FIG. 12, the primary rule set reader 1214uses Rule i having the index value “A” output by the secondary rulereader and primary rule set generator 1210 to find the bit string“010110100100” within the primary RCD 830, and passes this data to thebit buffer 1218.

Periodically data held within the bit buffer 1216 may be copied to amedia data buffer 1220 that is configured to queue multimedia data(e.g., multimedia data packets according to the original media dataformat) for rendering by a conventional media rendering application1222. The storage format and operations in blocks 1220 and 1222 may bethose of whatever media rendering application executes in thesubscriber's computing device to render the multimedia.

Thus, in the method 1200 illustrated in FIG. 12, a computing devicereceives secondary rule sets by any of a variety of communicationnetworks and protocols, uses each secondary rule to look up acorresponding primary rule in a secondary or subscriber RCD, uses eachprimary rule to look up a corresponding string of bits within a primaryRCD stored as a memory file, accumulates the identified bit strings intoa media play buffer that supports (i.e., provides media data to) aconventional media rendering application. This enables the variousembodiments to be used for transporting multimedia files of any formatusing any conventional communication network or protocol, includingcommunication protocols not suitable for carrying the originalmultimedia data format, to computing devices for rendering using anyconventional multimedia player or application compatible with theoriginal multimedia data format.

FIG. 13A illustrates algorithms or methods 1300 that may be implementedon one or more servers of a media delivery service for sending amultimedia file (e.g., streaming video) to a subscriber computing deviceusing the techniques described above with reference to FIGS. 11A-12.With reference to FIGS. 1-13A, the algorithms or methods 1300 may beimplemented by one or more servers or other computing devices within amedia delivery service provider and one or more processors (e.g., 202)in a subscriber computing device with access to memory storing asynchronized primary RCD.

The methods 1300 may be implemented by a media delivery service (e.g.,Netflix, Amazon, Hulu, etc.) for delivering movies and similarmultimedia files to subscribers. To support such deliveries, the mediadelivery service may implement a subscription sign-up method 1302 a bywhich the service provides one or more synchronized primary RCDs and asynchronized secondary or subscriber RCD to a new subscriber computingdevice, which implements a subscription registration process 1302 b. Forexample, a server of the media delivery service may obtain one or morestored media primary RCDs and a subscriber RCD in block 1312. Such RCDsmay be of a variety of formats including the examples described above.The primary RCD(s) may be generated for particular types of multimedia(e.g., specific movie genres) as described below with reference to FIGS.11A-14. The subscriber RCD may be unique to the subscriber computingdevice, or may be optimized for primary rule look up after beingtransformed according to a transformation rule.

In block 1314 a, the server may transmit the primary RCDs and subscriberRCD to the subscriber computing device that receives and saves the RCDsin blocks 1314 b and 1316 b, such as during a subscription sign-up. Thisdelivery may use any of a variety of forms, such as providing the RCDsfor download from a website. In block 1316 a, the server may storeinformation regarding the subscriber that will be used in subsequentmedia delivery operations, such as information regarding the particularRCDs that were downloaded to the subscriber computing device.

To prepare a multimedia file for delivery using various embodiments, aserver or other type of computing device of the media delivery serviceprovider may perform operations in method 1304 to transform themultimedia file into one or more secondary rule sets for delivery to asubscriber. For ease of reference, the computing device used toimplement the method 1304 is referred to herein as a “server,” however,this reference is not intended to be limiting as the operations may beperformed by a workstation, mainframe computer, matrix of personalcomputers, or other type of computing device.

In block 1018, the server may obtain or access a multimedia file (e.g.,a movie file) for processing. For example, the server may access a moviewithin a server farm of stored movie files.

In block 1020, the server may select the beginning (e.g., first bit) ofthe raw binary data of the media file as a starting point of the processof converting to a rule set linked to the RCD.

In block 1022, the server, such as using a rule set generatorapplication executing the server, may begin comparing a sequence of bitsof the raw binary data beginning from the selected starting point to theprimary RCD to identify a long matching string of bits that appearswithin the RCD data. As described above with reference to FIG. 11A thismay be accomplished by reading in a string of bits from the multimediafile while so long as matches to the string of bits can be located inthe RCD. A long string of bits may be identified when an additional bitcannot be matched to a string within the RCD or the length of the stringreaches a preset maximum or threshold length. In some embodiments, theprimary RCD may be indexed or otherwise enhanced with metadata thatenables the server to quickly identify matching bit strings. Suchindexing or metadata may be possible because the primary RCD may bepopulated with bit strings that appear frequently based on analyses of anumber of multimedia files (e.g., movies within a particular genre). Asan example of a metadata enhancement, the bit strings stored in the RCDmay include information indicating whether a longer bit string includingthe same bits is present in the RCD and if so provide indexes of bitstrings to compare. For example, if a particular long string is matched,metadata associated with the matched bit string may inform the serverthere are no longer bit string including the matched bits in the RCD sothe server can stop the search and use the matched bit string. Asanother example, if a particular long string is matched, metadataassociated with the matched bit string may inform the server of theindices (or other locating information) of longer bit strings includingthe matched bits in the RCD so the server can compare the multimediadata bits to those longer strings in the search for the longest matchingbit string.

Once a long string of bits is identified in block 1022, the server maygenerate a primary rule for locating or recovering the string of bitswithin/from the primary RCD in block 1322. The primary rule may begenerated using any of a variety of methods, including methods describedabove, depending upon the data structure of the primary RCD. Forexample, a primary rule may be the index (or other locating information)of the matched long bit string within the primary RCD.

In block 1324, the server may compare the primary rule to the subscriberRCD to identify a matching bit string (or matching value) and generate asecondary rule for locating the matched bit string within the subscriberRCD.

In block 1326, the server may store the generated secondary rule in arule set sequence file.

In determination block 1030, the processor may determine whether theentire multimedia file has been compared to the primary RCD.

In response to determining that the entire multimedia file has not beencompared to the primary RCD (i.e., determination block 1030=“No”), theprocessor may select the bit within the multimedia file following thelast bit in the previously matched bit string as the starting point forthe next comparison in block 1032, and then compare the sequence of bitsof the raw binary data beginning from the newly selected starting pointto the primary RCD to identify a long matching stream that appearswithin the primary RCD data in block 1022 as described above. Thus, theoperations of matching strings of bits to the primary RCD to identifylong strings of bits and rules for finding those long strings in theprimary RCD and then generating secondary rules for finding the primaryrules within the subscriber RCD may continue until the entire multimediafile has been compared to the primary RCD.

In response to determining that the entire multimedia file has beencompared to the primary RCD (i.e., determination block 1030=“Yes”), theprocessor may store the secondary rule sets generated in block 1324 forlater use in response to a request to play the media file received froma subscriber. By linking long strings of bits to primaryRCD-lookup-rules that are relatively small and then linking the primaryrules to secondary rules based on a subscriber RCD, the method 1300 mayenable delivery of movie-length multimedia files to subscriber computingdevices using communication methods that have limited bandwidth or asmall maximum file size while providing DRM protections. Further, therule sets may be broken into separate messages that are transmittedwithin message size limits.

The subscriber computing device may perform method 1306 b in order todownload and render a multimedia file (e.g., a movie) from the mediadelivery service. For example, a processor of the subscriber computingdevice may transmit a request for a particular media file to the mediadelivery service in block 1040 using any of a variety of communicationmethods (e.g., accessing a website, transmitting a request via anapplication, sending an email, etc.).

The media delivery server may respond to a request for a multimedia fileby executing operations of method 1306 a. In block 1042, the server mayreceive the request of the media file from the subscriber computingdevice, and access data for delivering the multimedia file to thesubscriber from memory. This may involve accessing information regardingthe particular subscriber computing device, such as a subscriberidentifier, information regarding the previously downloaded RCDs and thesubscriber RCD, and information related to the subscriber's account.

In block 1344, the server may generate a transformation rule fortransforming or otherwise randomizing the subscriber RCD and apply thetransformation rule to the secondary rule sets for the requestedmultimedia file in block 1346. In some embodiments, the secondary rulesets for the particular media file previously generated in method 1304 amay be altered consistent with how the transformation rules generated inblock 1344 will cause the subscriber RCD to be modified. In this mannerthe rule sets sent to the subscriber computing device will only work inidentifying the primary rules for identifying bit streams of theparticular multimedia file using the subscriber's RCD after that RCD hasbeen transformed according to the rotation rule. Thus, the secondaryrule sets transmitted to each subscriber computing device for a givenmedia file may be different.

In block 1348, the server may begin streaming the stored and transformedsecondary rule sets for the requested media file to the subscribercomputing device. Again, the delivery of the secondary rule sets to thesubscriber computing device may use any known or future form of datacommunication suitable for streaming data delivery. Examples includestreaming data via Internet HTTP protocol, mobile streaming mediaprotocols, etc.

In block 1350, the subscriber computing device may receive thesubscriber RCD transformation rule from the media service providerserver and apply the transformation rule to transform the subscriber RCDaccordingly in block 1352. By transforming the subscriber RCD in thismanner, the subsequently received secondary rules will correspond to thecorrect primary rules for obtaining bit strings for the selected mediafile from the primary RCD.

In block 1354, the subscriber computing device may begin receiving rulesand optionally buffering secondary rules from the server of the mediadelivery service.

In block 1356, the processor of the subscriber computing device mayselect the first secondary rule within the secondary rulesreceived/buffered in block 1354.

In block 1357, the processor may use the selected secondary rule toobtain the corresponding from the subscriber RCD. As described withreference to FIG. 12, the processor may perform this operation using asecondary rule reader primary rule set generator application 1210 orsoftware to apply the information in the secondary rule to identify thesequence of bits within the subscriber RCD and use that information asthe corresponding primary rule.

In block 1358, the processor may use the generated primary rule toobtain the correlated bit string from the primary RCD. As described withreference to FIG. 12, the processor may perform this operation using aprimary rule set reader application 1214 or software to apply theinformation in the rule to identify the sequence of bits within theprimary RCD and copy that bit string.

In block 1060, the processor of the subscriber computing device may addthe obtained bit string to a rendering bit buffer or memory file insequence. In this operation, the processor may store the bit stringcopied from the primary RCD into the buffer or memory file adjacent to(i.e., concatenated with) the previously stored bit string.

In determination block 1362, the processor may determine whether enoughdata has been received and added to the rendering buffer to enablerendering of a complete frame of the original media file. Thisdetermination may depend upon the amount of data that appears in thebuffer, or the presence within the data of a flag or demarcation dataindicating the start or end of a frame of data as may appear in theoriginal media file format.

In response to determining that enough data appears in the renderingbuffer for a media frame (i.e., determination block 1062=“Yes”), thedata within the rendering buffer may be passed to a media application inblock 1064. Again, the media application may be any known orconventional video rendering application that is capable of renderingthe original media file format. Many such media applications include abuffer or memory queue for accepting and temporarily streaming data asdata packets are received and assembled so that a constant stream ofmedia data can be provided to a rendering process. The operations inblock 1364 may direct data to any such buffer or memory queue, therebysupporting interoperability with a media rendering application.

In response to determining that insufficient data to support rendering aframe has been received in the rendering buffer (i.e., determinationblock 1062=“No”), or before or after buffer data is passed to the mediaapplication in block 1064, the processor of the subscriber computingdevice may determine whether another secondary rule has been received indetermination block 1366. In this embodiment addressing the rendering ofstreaming media files, this determination may be equivalent todetermining whether streaming of the media file is finished orsuspended.

In response to determining that another secondary rule has been receivedfor processing (i.e., determination block 1366=“Yes”), the processor mayselect the next secondary rule in block 1368, and use this selectedsecondary rule to obtain the next primary rule from the subscriber RCDin block 1357 and proceed with the operations in blocks 1358-1368 untilthe subscriber computing device stops receiving streamed secondary rulesThus, in response to determining that no more secondary rules remain toprocess (i.e., determination block 1366=“No”), the processor may end themethod.

The algorithms or methods 1300 b for implementing the embodimentsillustrated in FIG. 11B are similar to those described above with thedifferences illustrated in FIG. 13B and FIG. 13C. Specifically, theoperations of registering a subscriber and synchronizing primary RCDsand a subscriber RCD (i.e., methods 1302 a and 1302 b), as well as theoperations for processing streamed secondary rules and generatingmultimedia data from the two RCDs in the subscriber computing device(i.e., method 1306 b) may be substantially the same as the operationsillustrated in FIG. 13A.

In the embodiments illustrated in FIG. 11B and described above, theprocesses of generating the primary rule set in the secondary rule setsare separated in time, with the secondary rule sets being generated ator close to the time of delivering multimedia file to the subscribercomputing device. FIG. 13B illustrates operations that may be performedby a server or other media delivery service in the first operation ofgenerating the primary rule set. With reference to FIGS. 1-13B, thealgorithms or method 1300 b may be implemented by one or more servers orother computing devices with access to memory storing a suitable primaryRCD (e.g., in RCD for the genre of the particular movie).

In block 1018, the server may select the media file for encoding. Inblock 10 20, the server may select the starting point in a raw bitstring of the selected media file.

In block 1020, the server may select the beginning (e.g., first bit) ofthe raw binary data of the media file as a starting point of the processof converting to a rule set linked to the RCD.

In block 1022, the server, such as using a rule set generatorapplication executing the server, may begin comparing a sequence of bitsof the raw binary data beginning from the selected starting point to theprimary RCD to identify a long matching string of bits that appearswithin the RCD data. As described above with reference to FIG. 11B, thismay be accomplished by reading in a string of bits from the multimediafile while so long as matches to the string of bits can be located inthe RCD. A long string of bits may be identified when an additional bitcannot be matched to a string within the RCD or the length of the stringreaches a preset maximum or threshold length. As described above, insome embodiments, the primary RCD may be indexed or otherwise enhancedwith metadata that enables the server to quickly identify matching bitstrings. Such indexing or metadata may be possible because the primaryRCD may be populated with bit strings that appear frequently based onanalyses of a number of multimedia files (e.g., movies within aparticular genre). As an example of a metadata enhancement, the bitstrings stored in the RCD may include information indicating whether alonger bit string including the same bits is present in the RCD and ifso provide indexes of bit strings to compare. For example, if aparticular long string is matched, metadata associated with the matchedbit string may inform the server there are no longer bit stringincluding the matched bits in the RCD so the server can stop the searchand use the matched bit string. As another example, if a particular longstring is matched, metadata associated with the matched bit string mayinform the server of the indices (or other locating information) oflonger bit strings including the matched bits in the RCD so the servercan compare the multimedia data bits to those longer strings in thesearch for the longest matching bit string.

In block 1322, the server may generate a primary rule for locating thelong matching bit string in the primary RCD. Again, this rule may dependupon the particular data structure (e.g., indexing) of the primary RCD.

In determination block 1030, the processor may determine whether theentire multimedia file has been compared to the primary RCD.

In response to determining that the entire multimedia file has not beencompared to the primary RCD (i.e., determination block 1030=“No”), theprocessor may select the bit within the multimedia file following thelast bit in the previously matched bit string as the starting point forthe next comparison in block 1032, and then compare the sequence of bitsof the raw binary data beginning from the newly selected starting pointto the primary RCD to identify a long matching stream that appearswithin the primary RCD data in block 1022 as described above. Thus, theoperations of matching strings of bits to the primary RCD to identifylong strings of bits and rules for finding those long strings in theprimary RCD may continue until the entire multimedia file has beencompared to the primary RCD.

In response to determining that the entire multimedia file has beencompared to the primary RCD (i.e., determination block 1030=“Yes”), theprocessor may store the primary rule sets for the multimedia file forlater use in response to a request to download the multimedia filereceived from a subscriber.

FIG. 13C illustrates operations in method 1306 c that may be performedby a server of the media delivery service at the time that download ofthe multimedia file has been requested by a subscriber. With referenceto FIGS. 1-13C, the algorithms or method 1306 c may be implemented byone or more servers or other computing devices with access to memorystoring the subscriber RCD associated with the subscriber requesting themedia download.

In block 1342, the server may receive a request for a particularmultimedia file from a subscriber computing device.

In block 1344, the server may generate a transformation rule to be usedfor transforming or otherwise securing the subscriber RCD. Thistransformation rule may be generated using any of the methods describedherein. In some embodiments, as part of the operation in block 1344, theserver may transmit the transformation rule to the subscriber computingdevice so that the processor of the subscriber computing device canapply that rule in preparation for receiving secondary rule sets fromthe server.

In block 1382, the server may transform the subscriber RCD using thegenerated transformation rule. This generates a unique RCD for theparticular media delivery event. Depending upon the initial subscriberRCD, the rotated RCD may be both unique to the subscriber and to theparticular media delivery event.

In block 1384, the server may select a first primary rule in the rulesets for the requested multimedia file.

In block 1386, the server may compare the selected primary rule to thesubscriber RCD to identify a matching bit string. This comparison may beaccomplished using any of the methods described herein.

In block 1388, the server may generate a secondary rule for locating theprimary rule within the subscriber RCD. As with other embodiments, thegenerated secondary rule will depend upon the data structure of thesubscriber RCD.

In block 1390, the server may store the generated secondary rule in arule set sequence file. In some embodiments, the server may also beginstreaming secondary rules from the rule set sequence file to therequesting subscriber computing device.

In determination block 1392, the server may determine whether allprimary rules have been compared to the subscriber RCD.

In response to determining that not all primary rules have been comparedto the subscriber RCD (i.e., determination block 1392=“No”), the servermay select the next primary rule in the rule sets for the multimediafile in block 1394, and compare the selected primary rule to thesubscriber RCD to identify matching bit string in block 1386, generate acorresponding secondary rule in block 1388, and store and/or transmittedthe generated secondary rule in block 1390 as described.

In response to determining that all primary rules have been compared tothe subscriber RCD (i.e., determination block 1392=“Yes”), the servermay send the subscriber RCD transformation rule to the subscribercomputing device if the rotation rule was not already transmitted inblock 1344, and begin streaming the generated secondary rule sets to thesubscriber computing device if the server have not already startedstreaming secondary rules to the subscriber computing device in block1390. In embodiments in which the subscriber RCD transformation rule hasalready been sent to the subscriber computing device and secondary rulesare being streamed to the subscriber computing device as they aregenerated (e.g., in block 1390), the processor may end the method as theentire media file will have been assembled for rendering at this point.

For applications in which the various embodiments are used fordelivering media files, such as streaming movie and video clips, the RCDmay be custom developed to provide large chunks of bits that appearfrequently in such files. Such a custom developed RCD may then enablemedia files to be transmitted with rules linked to a set of frequentlyrepeating large strings of bits. This may enable the RCD to be smallerin size since the information contained in the RCD files are bit stringsthat are likely to be matched to the media file being transmitted,leaving out data that is unlikely to match to portions of the mediafile.

As described above, such custom developed RCDs may be developed byindividual media service providers (e.g., Netflix, Amazon, Hulu, etc.)to their own media transmission requirements. For example, each mediadelivery service provider may have their own proprietary RCD files thatare shared with subscribers upon sign-up. Thus, a rule set from a givenmedia service provider for a particular media file (e.g., a movie) canonly be used with the RCD of that media service provider. Additionally,media service providers may generate multiple RCDs, such as fordifferent genre or types of media files to be delivered.

A variety of methods may be used for generating custom RCDs fortransmitting media. In general, such methods may involve scanning one ormore media files to identify large chunks of bits that appear multipletimes within media files, and generating a database or data table ofsuch bit chunks correlated to an index or rule set. FIG. 14 illustratesa nonlimiting example of one such method 1400 for purposes ofdemonstrating how one of skill ordinary in the art may process mediafiles to generate a custom RCD.

Referring to FIG. 14, the method 1400 may be implemented on a server ora system of multiple servers (e.g., within a server farm) with access toa large memory. The operations of the method 1400 may be performedoffline and over a long period of time.

In block 1402, the server may create a working copy of one or more mediafiles, such as by copying an entire movie file into memory accessible tothe server. The creation of a working copy enables the processor tomanipulate the data without affecting the media file that will beprovided to subscribers. In some embodiments or implementations, only asingle file may be copied in block 1402. In some embodiments orimplementations, multiple media files, such as several movies of aparticular genre, may be copied into a single working file to enableidentification of bit string chunks that appear in all of the mediafiles.

In block 1404, the server may select and initial chunk size to use forsearching for repeating bit string chunks. The initial chunk size may bedetermined statistically based on an analysis of the media file.Alternatively, the chunk size may be selected arbitrarily based on thenature of the media file to be distributed. For example, the maximumchunk size may be limited to the data in a single frame of the moviefile as it is unlikely that different movies will include an identicalsequence of image frames. As another example, the initial chunk size maybe limited to one half (or another fraction) of the size of a singleframe of a movie file.

In block 1406, the server may select a starting string of bits of theselected chunk size within the media file. In some embodiments, theserver may start with the first bit and include all of the bitssequentially up to the selected chunk size. In some embodiments, theserver may start somewhere within the media file, such as following ametadata portion of the media file beginning where the rendered imagedata begins to appear. In this operation, the server may copy all of thebits from the media file starting from the first bit at the selectedstarting point through the end of the selected chunk size. In someembodiments, the server may copy this selected string of bits to aportion of memory that is readily accessible, such as a large buffer orcomparison register.

In block 1408, the server may select a starting point for a chunk sizewindow within the media file. The bits in the media file within thechunk size window from the starting point will be compared to the stringof bits selected in block 1406 (and later in block 1428).

In block 1410 and determination block 1412, the server may compare theselected string of bits to the bits within the chunk size window todetermine whether there is a match. In some embodiments, this comparisonmay simply be a bit to bit comparison of the string of bits temporarilystored in memory to the bits within the chunk size window of the mediafile. In some embodiments, any of a number of algorithms may be used tosimplify or shorten the comparison operation, such as rapidlydetermining that there is no match based on a simple calculation orhash. For example, the bits within the chunk size window of the mediafile may be processed in a hash routine to generate a hash result thatmay be compared to a hash of the string of bits stored in memory. Thehash may be run on the selected string of bits at the time those bitsare selected (i.e., in block 1406 or block 1428), and then run on thebits within the chunk size window as an initial comparison step. If thehash results do not match, then the strings of bits will also not match,and therefore no further comparisons may be needed. Further sampling ofselected bits may be performed to quickly eliminate nonmatching windowsof media file bits, such as comparing first and last bits to the firstand last bits of the selected string. Thus, the comparison performed inblock 1410 and determination block 1412 may be accomplished quicklyexcept for cases where there is a match or a near match, in which case abit by bit comparison may be performed after initial filtering or hashcomparisons are performed.

In response to determining that the bits within the chunk size window ofthe working media file match the string of bits of the selected chunksize (i.e., determination block 1412=“Yes”), the server may temporarilystore the location within the working copy of the media file of thechunk size window matching the string of bits in optional block 1414,and increment a count of the number of times that the string of bitsmatches bits within the chunk size window in block 1416. Storing thetemporary location of the chunk size window within the working mediafile is optional because the information is not needed to generate RCD,but may be used later to delete those bits from the working file inblock 1426 as described below as a way to speed the analysis of theworking copy of the media file by avoiding comparing those same bits toother strings of bits.

In response to determining that the bits within the chunk size window ofthe working media file do not match the string of bits of the selectedchunk size (i.e., determination block 1412=“No”) or after the operationsin optional block 1414 and block 1416, the server may shift the chunksize window within the working copy of the media file a predeterminedincrement, such as a single bit or one byte.

In determination block 1420, the server may determine whether the end ofthe working copy of the media file is reached within the shifted chunksize window.

In response to determining that the end of the working copy of the mediahas not been reached within the shifted chunk size window (i.e.,determination block 1420=“No”), the server may again compare theselected string of bits to the bits within the chunk size window of theworking media file in block 1410 and determination block 1412 asdescribed. Thus, in the operations blocks 1410 through 1420, the servermay incrementally compare the selected string of bits to the workingcopy of the media file in shifting windows until the entire media filehas been compared.

In response to determining that the end of the working copy of the mediafile has been reached within the shifted chunk size window (i.e.,determination block 1420=“Yes”), the server may compare the number oftimes that the selected string of bits matched the bits within the chunksize window to a threshold value in determination block 1422. Thiscomparison may be used to determine whether the selected string of bitsmatches strings of bits within the media file frequently enough tojustify including the string within the RCD. For example, the thresholdmay be 2 or more. There may be a trade-off between the size of the RCDin the threshold for the chunk match count that a media delivery servicemay want to adjust. On the one hand, the larger the string of bitsassociated with a single rule or index, the more information that iscommunicated with that rule/index. On the other hand, a large string ofbits matching only a few portions of a media file will increase the sizeof the RCD but may not result in a significant reduction in the amountof information transmitted (i.e., the rule set) when delivering themedia file to consumer.

In response to determining that the number of times that the selectedstring of bits matched bits within the chunk size window of the workingmedia file equals or exceeds the threshold value (i.e., determinationblock 1422=“Yes”), the server may store the selected string of bits tothe RCD along with an index for location rule for finding the thatstring of bits within the RCD in 1424. In some embodiments, the selectedstring of bits may be stored to the RCD in a new record within adatabase, with the index being an identifier of that record. In someembodiments, the selected string of bits may be stored to the RCDadjacent to the previously stored bits, and a rule may be generated toenable finding where the selected string of bits begins in the RCD, suchas starting point and string length values.

In optional block 1426, the server may delete all of the matchingstrings of bits from the working copy of the media file using thetemporarily stored locations of the matched string bits temporarilystored in block 1414. As noted above, the leading matched strings ofbits from the working copy of the media file will reduce the amount ofdata that is compared in subsequent passes through the method 1400,which may accelerate the generation of the RCD. On the other hand, notthe leading the matched strings of bits will enable the method toidentify smaller strings of bits (i.e., using smaller chunk sizes) thathave a high frequency of occurrence.

In response to determining that the number of times that the string ofbits matches bits within the chunk size window is less than thethreshold (i.e., determination block 1422=“No”), or after storing theselected strings of bits to the RCD in block 1424, the server may selecta next string of bits of the selected chunk size within the media filein block 1428. At this point in the method 1400, the server has comparedthe previously selected string of bits to all bits within the workingcopy of the media file, counted the number of matches, and stored thestring of bits to the RCD if there are a sufficient number of matches.Thus, the server selects the next string of bits to be compared to theworking copy of the media file in chunk size windows. In someembodiments, the server may select the next string of bits beginningwith the next bit, thus overlapping the previous string of bits by allthe one bit. In some embodiments, the server may select the next stringof bits beginning a certain number of bits, such as one byte, from thestart of the previous selected string of bits.

In determination block 1430, the server may determine whether theselected next string of bits includes the end of the working copy of themedia file. Said another way, the server may determine in determinationblock 1430 whether every string of bits of the selected chunk size havebeen compared through the working copy of the media file.

In response to determining that the end of the media file is notincluded in the selected string of bits (i.e., determination block1430=“No”), the server may select a starting point for a chunk sizewindow in the working copy of the media file in block 1408 and repeatthe operations of comparing the newly selected string of bits to bitswithin a moving chunk size window of the working copy of the media filein blocks 1410-1426 as described above. Thus, until the selected stringof bits reaches the end of the media file, the server compares stringsof bits equal to the selected chunk size (determined in either block1406 or 1432) to bits within the working copy of the media file.

In response to determining that the end of the media file is included inthe selected string of bits (i.e., determination block 1430=Yes”), theserver may decrement the selected chunk size by an amount in block 1432.Said another way, having compared all or substantially all of thestrings of bits within the media file with a length equal to thepreviously selected chunk size to windows of bits of the same chunk sizewithin the working copy of the media file, and stored to the RCD thestrings of bits of that length found to be repeating multiple times, theserver reduces the size of the of the chunks that are compared in a nextiteration of the operations of the method 1400 from block 1406 todetermination block 1430. The amount by which the selected chunk size isdecremented in block 1432 may vary. For example, the chunk size may bedecremented by one bit in some embodiments. As another example, thechunk size may be decremented by one byte in some embodiments. Asanother example, the chunk size may be reduced by a factor of two insome embodiments.

Incrementally reducing the chunk size for subsequent iterations of themethod 1400 enables the server to identify shorter repeating strings ofbits. As the chunk size reduces with each iteration, the frequency ofrepeating strings of bits is anticipated to increase. In an initialiteration through of the method 1400, there may be no repeating stringsof bits with a length equal to the initially selected chunk size, andthe first few passes through the method 1400 may yield no additions tothe RCD until the selected chunk size reaches a point at which multiplerepetitions of bit strings begin to be observed.

In determination block 1434, the server may determine whether the newlyselected chunk size is less than a minimum chunk length. The minimumchunk length may be a size of bits strings below which there is littlebenefit in terms of information communicated to a receiver device byproviding an index or rule to the RCD instead of communicating the rawdata directly. In other words, if the index or rule required to identifythe location in the RCD of a string of bits requires the same number ofbits is in the string, there is little to no benefit of referring to theRCD. For example, if the index or rule required to identify the locationin the RCD of a string of bits requires three bytes of data, the minimumlength for the chunk size may be 4 bytes (i.e., 32 bits).

In response to determining that the chunk size selected in block 1432 isgreater than the minimum length (i.e., determination block 1434=“No”),the server may select a starting string of bits of the selected chunksize within the media file in block 1406 and repeat the operations ofblocks 1406 through 1434 as described above.

In response to determining that the chunk size selected in block 1432 isless than the minimum length (i.e., determination block 1434=“Yes”), theserver may store the RCD along with an index or rule set for use in thevarious embodiments because the entire media file has been analyzed andthe RCD populated with multiple repeating strings of bits.

Various embodiments illustrated and described are provided merely asexamples to illustrate various features of the claims. However, featuresshown and described with respect to any given embodiment are notnecessarily limited to the associated embodiment and may be used orcombined with other embodiments that are shown and described. Further,the claims are not intended to be limited by any one example embodiment.For example, one or more of the operations of the methods 400, 500, 600,700, 800 a, 800 b, 900 a, 900 b, 1000, 1100 a, 1100 b, 1200, 1300, 1302a, 1304 a, 1306 a, 1302 b, 1304 b, 1306 b, 1306 c, and 1400 may besubstituted for or combined with one or more operations of the methods400, 500, 600, 700, 800 a, 800 b, 900 a, 900 b, 1000, 1100 a, 1100 b,1200, 1300, 1302 a, 1304 a, 1306 a, 1302 b, 1304 b, 1306 b, 1306 c, and1400.

FIG. 15 is a component block diagram of a mobile wireless communicationdevice 1500 suitable for implementing various embodiments. Withreference to FIGS. 1A-15, the mobile wireless communication device 1500may include a processor 1502 coupled to a touchscreen controller 1506and an internal memory 1504. The processor 1502 may be one or moremulti-core integrated circuits designated for general or specificprocessing tasks. The internal memory 1504 may be volatile ornon-volatile memory, and may also be secure and/or encrypted memory, orunsecure and/or unencrypted memory, or any combination thereof. Thetouchscreen controller 1506 and the processor 1502 may also be coupledto a touchscreen panel 1512, such as a resistive-sensing touchscreen,capacitive-sensing touchscreen, infrared sensing touchscreen, etc.Additionally, the display of the mobile wireless communication device1500 need not have touch screen capability.

The mobile wireless communication device 1500 may have two or more radiosignal transceivers 1508 (e.g., Bluetooth, Zigbee, Wi-Fi, radiofrequency (RF), etc.) and antennae 1510, for sending and receivingcommunications, coupled to each other and/or to the processor 1502. Thetransceivers 1508 and antennae 1510 may be used with the above-mentionedcircuitry to implement the various wireless transmission protocol stacksand interfaces. The mobile wireless communication device 1500 mayinclude one or more cellular network wireless modem chip(s) 1516 coupledto the processor and antennae 1510 that enables communication via two ormore cellular networks via two or more radio access technologies.

The mobile wireless communication device 1500 may include a peripheralwireless device connection interface 1518 coupled to the processor 1502.The peripheral wireless device connection interface 1518 may besingularly configured to accept one type of connection, or may beconfigured to accept various types of physical and communicationconnections, common or proprietary, such as USB, FireWire, Thunderbolt,or PCIe. The peripheral wireless device connection interface 1518 mayalso be coupled to a similarly configured peripheral wireless deviceconnection port (not shown).

The mobile wireless communication device 1500 may also include speakers1514 for providing audio outputs. The mobile wireless communicationdevice 1500 may also include a housing 1520, constructed of a plastic,metal, or a combination of materials, for containing all or some of thecomponents discussed herein. The mobile wireless communication device1500 may include a power source 1522 coupled to the processor 1502, suchas a disposable or rechargeable battery. The rechargeable battery mayalso be coupled to the peripheral wireless device connection port toreceive a charging current from a source external to the mobile wirelesscommunication device 1500. The mobile wireless communication device 1500may also include a physical button 1524 for receiving user inputs. Themobile wireless communication device 1500 may also include a powerbutton 1526 for turning the mobile wireless communication device 1500 onand off.

Other forms of computing devices may also benefit from the variousaspects. Such computing devices typically include the componentsillustrated in FIG. 16, which illustrates an example laptop computer1600. With reference to FIGS. 1A-16, the computer 1600 generallyincludes a processor 1601 coupled to volatile memory 1602 and a largecapacity nonvolatile memory, such as a disk drive 1603. The computer1600 may also include a compact disc (CD) and/or DVD drive 1604 coupledto the processor 1601. The computer 1600 may also include a number ofconnector ports coupled to the processor 1601 for establishing dataconnections or receiving external memory devices, such as a networkconnection circuit 1605 for coupling the processor 1601 to a network.The computer 1600 may also include a display 1607, a keyboard 1608, apointing device such as a trackpad 1610, and other similar devices.

Various embodiments may employ a computing device as a network elementof a communication network. Such network elements may typically includeat least the components illustrated in FIG. 17, which illustrates anexample network element, server device 1700. With reference to FIGS.1A-17, the server device 1700 may typically include a processor 1701coupled to volatile memory 1702 and a large capacity nonvolatile memory,such as a disk drive 1703. The server device 1700 may also include aperipheral memory access device such as a floppy disc drive, compactdisc (CD) or digital video disc (DVD) drive 1706 coupled to theprocessor 1701. The server device 1700 may also include network accessports 1704 (or interfaces) coupled to the processor 1701 forestablishing data connections with a network, such as the Internetand/or a local area network coupled to other system computers andservers. Similarly, the server device 1700 may include additional accessports, such as USB, Firewire, Thunderbolt, and the like for coupling toperipherals, external memory, or other devices.

The processors 1502, 1601, 1701 may be any programmable microprocessor,microcomputer or multiple processor chip or chips that can be configuredby software instructions (applications) to perform a variety offunctions, including the functions of the various aspects describedbelow. In some mobile devices, multiple processors 1602 may be provided,such as one processor dedicated to wireless communication functions andone processor dedicated to running other applications. Typically,software applications may be stored in the internal memory 1504, 1602,1702 before they are accessed and loaded into the processor 1502, 1601,1701. The processor 1502, 1601, 1701 may include internal memorysufficient to store the application software instructions.

Various embodiments may be implemented in any number of single ormulti-processor systems. Generally, processes are executed on aprocessor in short time slices so that it appears that multipleprocesses are running simultaneously on a single processor. When aprocess is removed from a processor at the end of a time slice,information pertaining to the current operating state of the process isstored in memory so the process may seamlessly resume its operationswhen it returns to execution on the processor. This operational statedata may include the process's address space, stack space, virtualaddress space, register set image (e.g., program counter, stack pointer,instruction register, program status word, etc.), accountinginformation, permissions, access restrictions, and state information.

A process may spawn other processes, and the spawned process (i.e., achild process) may inherit some of the permissions and accessrestrictions (i.e., context) of the spawning process (i.e., the parentprocess). A process may be a heavy-weight process that includes multiplelightweight processes or threads, which are processes that share all orportions of their context (e.g., address space, stack, permissionsand/or access restrictions, etc.) with other processes/threads. Thus, asingle process may include multiple lightweight processes or threadsthat share, have access to, and/or operate within a single context(i.e., the processor's context).

The foregoing method descriptions and the process flow diagrams areprovided merely as illustrative examples and are not intended to requireor imply that the blocks of various embodiments must be performed in theorder presented. As will be appreciated by one of skill in the art, theorder of blocks in the foregoing embodiments may be performed in anyorder. Words such as “thereafter,” “then,” “next,” etc. are not intendedto limit the order of the blocks; these words are simply used to guidethe reader through the description of the methods. Further, anyreference to claim elements in the singular, for example, using thearticles “a,” “an” or “the” is not to be construed as limiting theelement to the singular.

The various illustrative logical blocks, modules, circuits, andalgorithm blocks described in connection with the embodiments disclosedherein may be implemented as electronic hardware, computer software, orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and blocks have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the claims.

The hardware used to implement the various illustrative logics, logicalblocks, modules, and circuits described in connection with theembodiments disclosed herein may be implemented or performed with ageneral purpose processor, a digital signal processor (DSP), anapplication specific integrated circuit (ASIC), a field programmablegate array (FPGA) or other programmable logic device, discrete gate ortransistor logic, discrete hardware components, or any combinationthereof designed to perform the functions described herein. Ageneral-purpose processor may be a microprocessor, but, in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of communication devices, e.g., acombination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, or any other such configuration. Alternatively, some blocks ormethods may be performed by circuitry that is specific to a givenfunction.

In various embodiments, the functions described may be implemented inhardware, software, firmware, or any combination thereof. If implementedin software, the functions may be stored as one or more instructions orcode on a non-transitory computer-readable medium or non-transitoryprocessor-readable medium. The operations of a method or algorithmdisclosed herein may be embodied in a processor-executable softwaremodule, which may reside on a non-transitory computer-readable orprocessor-readable storage medium. Non-transitory computer-readable orprocessor-readable storage media may be any storage media that may beaccessed by a computer or a processor. By way of example but notlimitation, such non-transitory computer-readable or processor-readablemedia may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or otheroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other medium that may be used to store desired programcode in the form of instructions or data structures and that may beaccessed by a computer. Disk and disc, as used herein, includes compactdisc (CD), laser disc, optical disc, digital versatile disc (DVD),floppy disk, and Blu-ray disc where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above are also included within the scope ofnon-transitory computer-readable and processor-readable media.Additionally, the operations of a method or algorithm may reside as oneor any combination or set of codes and/or instructions on anon-transitory processor-readable medium and/or computer-readablemedium, which may be incorporated into a computer program product.

The preceding description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the claims. Variousmodifications to these embodiments will be readily apparent to thoseskilled in the art, and the generic principles defined herein may beapplied to other embodiments without departing from the scope of theclaims. Thus, the present disclosure is not intended to be limited tothe embodiments shown herein but is to be accorded the widest scopeconsistent with the following claims and the principles and novelfeatures disclosed herein.

What is claimed is:
 1. A method of receiving a data file in a firstcomputing device from a second computing device, comprising: storing areferential complex dataset (RCD) in memory of the first computingdevice that matches an RCD stored in the second computing device;receiving a rule set from the second computing device; sequentiallyusing each rule in the rule set to identify corresponding bit strings inthe RCD in memory; and copying the identified bit strings into a memoryto replicate the data file.
 2. The method of claim 1, furthercomprising: processing the replicated data file using an applicationcompatible with the data file.
 3. The method of claim 1, furthercomprising: storing a subscriber RCD in memory of the first computingdevice; receiving a secondary rule set from the second computing device;sequentially using each secondary rule in the secondary rule set toidentify corresponding bit strings in the subscriber RCD in memory;using the identified corresponding bit strings in the subscriber RCD asrule to identify corresponding bit strings in the RCD in memory; andcopying the identified bit strings into a memory to replicate the datafile.
 4. A computing device, comprising: a memory; and a processorcoupled to the memory and configured with processor-executableinstructions to perform operations comprising: storing a referentialcomplex dataset (RCD) in memory of the computing device that matches anRCD stored in a second computing device; receiving a rule set from thesecond computing device; sequentially using each rule in the rule set toidentify corresponding bit strings in the RCD in memory; and copying theidentified bit strings into a memory to replicate the data file.
 5. Thecomputing device of claim 4, further comprising: processing thereplicated data file using an application compatible with the data file.6. The computing device of claim 4, further comprising: storing asubscriber RCD in memory of the first computing device; receiving asecondary rule set from the second computing device; sequentially usingeach secondary rule in the secondary rule set to identify correspondingbit strings in the subscriber RCD in memory; using the identifiedcorresponding bit strings in the subscriber RCD as rule to identifycorresponding bit strings in the RCD in memory; and copying theidentified bit strings into a memory to replicate the data file.
 7. Anon-transitory processor-readable storage medium having stored thereonprocessor-executable instructions configured to cause a processor of acomputing device to perform operations comprising: storing a referentialcomplex dataset (RCD) in memory of the computing device that matches anRCD stored in a second computing device; receiving a rule set from thesecond computing device; sequentially using each rule in the rule set toidentify corresponding bit strings in the RCD in memory; and copying theidentified bit strings into a memory to replicate the data file.
 8. Thenon-transitory processor-readable storage medium of claim 7, wherein thestored processor-executable instructions are configured to cause theprocessor of the computing device to perform operations furthercomprising: processing the replicated data file using an applicationcompatible with the data file.
 9. The non-transitory processor-readablestorage medium of claim 7, wherein the stored processor-executableinstructions are configured to cause the processor of the computingdevice to perform operations further comprising: storing a subscriberRCD in memory of the computing device; receiving a secondary rule setfrom the second computing device; sequentially using each secondary rulein the secondary rule set to identify corresponding bit strings in thesubscriber RCD in memory; using the identified corresponding bit stringsin the subscriber RCD as rule to identify corresponding bit strings inthe RCD in memory; and copying the identified bit strings into a memoryto replicate the data file.